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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 5 Jan 2012, Avi Kivity wrote:
> 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)

If the MemoryRegions are re-created by the devices, then we need another
mechanism to find out where the videoram is.
What I am saying is that the suggestion of having a xen_address field
for every MemoryRegion would make the code cleaner but it would not
solve the save/restore issue described in the previous email.


> > 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.

I agree, however xen_register_framebuffer is called after
memory_region_init_ram, so the allocation would have been made already.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel