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

[Stefano Stabellini]

On Mon, 12 Dec 2011, Jan Kiszka wrote:
> >>>> Is there really no way to fix this properly in the Xen layer?
> >>>
> >>> We thought about this issue for some time but we couldn't come up with
> >>> anything better.
> >>> To summarize the problem:
> >>>
> >>> - on restore the videoram has already been loaded in the guest physical
> >>>   address space by Xen;
> >>>
> >>> - we don't know exactly where it is yet, because it has been loaded at
> >>>   the *last* address it was mapped to (see map_linear_vram_bank that
> >>>   moves the videoram);
> >>>
> >>> - we want to avoid allocating the videoram twice (actually the second
> >>>   allocation would fail because of memory constraints);
> >>>
> >>>
> >>>
> >>> So the solution (I acknowledge that it looks more like an hack than a
> >>> solution) is:
> >>>
> >>> - wait for cirrus to load its state so that we know where the videoram
> >>>   is;
> >>
> >> Why can't you store this information in some additional Xen-specific
> >> vmstate? The fact that memory_region_get_ram_ptr has to return NULL
> >> looks bogus to me. It's against the QEMU semantics. Other devices may
> >> only be fine as they are not (yet) used with Xen.
> > 
> > Unfortunately that cannot work because the allocation is done by
> > vga_common_init before any state has been loaded.
> > So even if we saved the physmap QLIST in a vmstate record, it wouldn't
> > be available yet when vga_common_init tries to allocate the memory.
> 
> If you run two VMs with identical setup, one from cold start to
> operational mode, the other into an incoming migration, the guest
> physical memory layout the host sees is different? Hmm, maybe if you
> reorder devices in the command line.

Yes, it is different because the memory allocated for a specific device
(Cirrus) has been moved (map_linear_vram_bank).


> Really, I think this is something inherently incompatible with the
> current memory API. If Xen has this unfixable special "requirement"
> (it's rather a design issue IMHO), adjust the API and adapt all devices.
> Hot-fixing only a single one this way is no good idea long term.

Fair enough.
What about introducing a type of savevm state that is going to be
restored before machine->init?
This way we could save and restore our physmap and we could handle
memory maps and allocations transparently.