Re: [Xen-devel] gross qemu behavior

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.03.14 at 18:46, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> But fortunately we don't actually need to add the VGA ROM to the guest
> physmap for it to work,

Is that true even when the ROM gets enabled by the guest?

> QEMU can trap and emulate. In fact even today we
> are not mapping it at the right place anyway, see xen_set_memory:
> 
>     if (add) {
>         if (!memory_region_is_rom(section->mr)) {
>             xen_add_to_physmap(state, start_addr, size,
>                                section->mr, section->offset_within_region);
>         } else {

Right - that's part of the problem. And it would seem to be better to
map it where it belongs (even if not enabled) than to have it sit at
some arbitrary place. But as that still wouldn't be correct, I'd clearly
prefer a proper solution.

> So the only solution I can see right now is:
> 
> - avoid allocating guest memory for the VGA ROM
> That means that at the beginning of xen_ram_alloc we need to realize
> that the memory region we are dealing with is the VGA ROM memory region
> and avoid calling xc_domain_populate_physmap_exact for it.
> 
> - call g_malloc instead
> Simply use g_malloc to allocate QEMU memory for the VGA ROM,
> keep track of the allocation in a data structure internal to xen-all.c.
> 
> - make sure that qemu_get_ram_ptr can deal with the different allocation
> Now that the VGA ROM is QEMU memory, we need to make sure that
> qemu_get_ram_ptr returns the right pointer for it.
> 
> 
> This is all very fiddly and hackish, but I can't see a better way of
> solving the issue.

Plus this all reads very VGA-special-casing to me, yet a proper model
would universally cover all PCI ROMs (emulated as well as passed
through).

Jan


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