All of lore.kernel.org
 help / color / mirror / Atom feed
* VMState in QEMU
@ 2020-07-20 10:58 Pratik Parvati
  2020-07-20 12:04 ` Philippe Mathieu-Daudé
  2020-07-20 13:40 ` Peter Maydell
  0 siblings, 2 replies; 3+ messages in thread
From: Pratik Parvati @ 2020-07-20 10:58 UTC (permalink / raw)
  To: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

Hi team,

Can someone please explain to me briefly the significance of VMState in
Migration. I understand that this reduces the lot of duplication of code
across all the devices in QEMU with the common put and get implementation
somewhere in the code. Does this have any other significance?

Is it mandatory to define the state of each device? Like, for example, I am
referring hw/arm/versatilepb.c; I see the VMState is defined for sic
(secondary interrupt controller) Whereas VMState is not defined for PL011
UART device. How do I know which device should be considered for VMState?

Below snippet is used as a reference

typedef struct vpb_sic_state {
    SysBusDevice parent_obj;

    MemoryRegion iomem;
    uint32_t level;
    uint32_t mask;
    uint32_t pic_enable;
    qemu_irq parent[32];
    int irq;
} vpb_sic_state;
static const VMStateDescription vmstate_vpb_sic = {
    .name = "versatilepb_sic",
    .version_id = 1,
    .minimum_version_id = 1,
    .fields = (VMStateField[]) {
        VMSTATE_UINT32(level, vpb_sic_state),
        VMSTATE_UINT32(mask, vpb_sic_state),
        VMSTATE_UINT32(pic_enable, vpb_sic_state),
        VMSTATE_END_OF_LIST()
    }
};

From the above code, it is definite that VMState is implemented as per the
device (I mean, there is no common structure for defining a VMState of the
device). From the migration point of view, how does this declaration help?

Thanks for your continuous support

Regards,

Pratik

[-- Attachment #2: Type: text/html, Size: 6234 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: VMState in QEMU
  2020-07-20 10:58 VMState in QEMU Pratik Parvati
@ 2020-07-20 12:04 ` Philippe Mathieu-Daudé
  2020-07-20 13:40 ` Peter Maydell
  1 sibling, 0 replies; 3+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-07-20 12:04 UTC (permalink / raw)
  To: Pratik Parvati, qemu-devel

On 7/20/20 12:58 PM, Pratik Parvati wrote:
> Hi team,
> 
> Can someone please explain to me briefly the significance of VMState in
> Migration.

This is documented in docs/devel/migration.rst. Which part of
this document is not clear enough to you? So we could improve
it.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: VMState in QEMU
  2020-07-20 10:58 VMState in QEMU Pratik Parvati
  2020-07-20 12:04 ` Philippe Mathieu-Daudé
@ 2020-07-20 13:40 ` Peter Maydell
  1 sibling, 0 replies; 3+ messages in thread
From: Peter Maydell @ 2020-07-20 13:40 UTC (permalink / raw)
  To: Pratik Parvati; +Cc: QEMU Developers

On Mon, 20 Jul 2020 at 11:59, Pratik Parvati <pratikp@vayavyalabs.com> wrote:
> Is it mandatory to define the state of each device? Like, for example, I am referring hw/arm/versatilepb.c; I see the VMState is defined for sic (secondary interrupt controller) Whereas VMState is not defined for PL011 UART device.

The PL011 does have VMState: it is in hw/char/pl011.c,
struct "vmstate_pl011". Generally the vmstate struct for
each device is in the source file where that device
is implemented. The SIC device is implemented in
the same versatilepb.c source file that the board model
is implemented in because it happens to be a simple
device used only by that one board, and so the SIC device's
vmstate is also in that source file. (The other reason
that the SIC device is in the versatile board's source
file is because it's quite old code -- these days we'd probably
put it in its own source file in hw/intc, but the coding style
back when that file was written over a decade ago was
different and devices often got put in the same
source file as the board model.)

thanks
-- PMM


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-07-20 13:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-20 10:58 VMState in QEMU Pratik Parvati
2020-07-20 12:04 ` Philippe Mathieu-Daudé
2020-07-20 13:40 ` Peter Maydell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.