Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.

[Avi Kivity <avi@redhat.com>]

On 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > The "solution" I am proposing is introducing an early_savevm set of
> > > save/restore functions so that at restore time we can get to know at
> > > what address the videoram is mapped into the guest address space. Once we
> > > know the address we can remap it into qemu's address space and/or move it
> > > to another guest physical address.
> > 
> > Why can we not simply track it?  For every MemoryRegion, have a field
> > called xen_address which tracks its location in the Xen address space
> > (as determined by the last call to xen_set_memory or qemu_ram_alloc). 
> > xen_address would be maintained by callbacks called from the memory API
> > into xen-all.c.
>
> Nice and simple, I like it.
> However we would still need an early_savevm mechanism to save and restore the
> MemoryRegions, unless they already gets saved and restored somehow?

MemoryRegions are instantiated by the devices, so they should be there
(creating a MemoryRegion == calling qemu_ram_alloc() in the old days)

> Maybe saving and restoring the list of MemoryRegions could be useful for
> the generic case too?

Unneeded, since they're an integral part of the devices.  However, it
would be good to have a list of the devices so we could send that over
instead of relying on invoking qemu with the same command-line arguments
on both sides - but that's something that qom is already tackling.

> > > The problem of avoiding a second allocation remains, but could be
> > > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
> > > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
> > > called "vga.vram" at restore time, and use the reference to the already
> > > allocated videoram instead.
> > 
> > Hacky
>
> Yes :/

xen_register_framebuffer() is slightly less hacky.

> > The allocation is not driven by qemu then?
>
> At restore time, it is not.
>
>
> > For the long term I suggest making qemu control the allocations (perhaps
> > by rpcing dom0); otherwise how can you do memory hotplug or PCI cards
> > with RAM (like ivshmem)?
>
> It is only the videoram (well, everything allocated with
> qemu_ram_alloc_from_ptr actually) and only at restore time, because
> the memory in question is being considered normal guest memory and
> therefore it is saved and restored by the hypervisor.
> Otherwise Qemu is the one that triggers these allocations, so there are
> no issues with memory hotplug and pci passthrough.

Okay.

-- 
error compiling committee.c: too many arguments to function