Re: [Xen-devel] gross qemu behavior

[Paolo Bonzini <pbonzini@xxxxxxxxxx>]

Il 28/03/2014 19:30, Stefano Stabellini ha scritto:
> On Fri, 28 Mar 2014, Paolo Bonzini wrote:
> > Il 28/03/2014 18:52, Stefano Stabellini ha scritto:
> > > > This is a thorny issue, fixing this behavior is not going to be trivial:
> > > >
> > > > - The hypervisor/libxc does not currently expose a
> > > >   xc_domain_remove_from_physmap function.
> > > >
> > > > - QEMU works by allocating memory regions at the end of the guest
> > > >   physmap and then moving them at the right place.
> > > >
> > > > - QEMU can destroy a memory region and in that case we could free the
> > > >   memory and remove it from the physmap, however that is NOT what QEMU
> > > >   does with the vga ROM. In that case it calls
> > > >   memory_region_del_subregion, so we can't be sure that the ROM won't be
> > > >   mapped again, therefore we cannot free it. We need to move it
> > > >   somewhere else, hence the problem.
> > Right; QEMU cannot know either if the ROM will be mapped again (examples
> > include "cd /sys/bus/pci/devices/0000:0:03.0 && echo 1 > rom && cat rom" or a
> > warm reset).
> >
> > > > But fortunately we don't actually need to add the VGA ROM to the guest
> > > > physmap for it to work, QEMU can trap and emulate. In fact even today we
> > > > are not mapping it at the right place anyway, see xen_set_memory:
> > But how can you execute from the VGA ROM then?
> I don't know, I guess we don't? In that case why does it work today?
Right, the ROM is copied down to low memory by firmware (hvmloader?).

> > Also, how do you migrate its contents?
> That would also not work. We would have to re-initialize it in QEMU on
> the receiving end.
That is problematic.  It would mean that a system reset after migration 
may auto-upgrade some parts of the firmware.
Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel