Re: [Xen-devel] gross qemu behavior

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.03.14 at 08:48, <JBeulich@xxxxxxxx> wrote:
> Having wasted enough time getting to this point, I'd like to ask you
> to advise a proper fix for this. We definitely shouldn't be leaving
> stuff sitting at arbitrary positions in the physical address space of
> the guest. And the fact that the range gets removed (from Xen's
> perspective, but not from qemu's) when RAM extends beyond
> 0xf0000000 (due to it being replaced with what is actually
> intended to be there) makes me wonder what would happen if the
> ROM got enabled by the guest.

Fixing of which would, afaict, also address the performance impacting
fact that the emulated MMIO ranges other than the frame buffer get
marked UC in the EPT tables if the domain has any passed through
devices (as then the call to xc_domain_pin_memory_cacheattr()
would get called for all such regions - care would of course need to
be taken to avoid calling it for MMIO regions of passed through
devices).

And looking at the cache attribute pinning I see that this is broken
too: The hypervisor doesn't even expose a removal interface, and
the adding one doesn't check whether the new region already exists
or conflicts with already existing ones. What if the guest decided to
relocate the region a couple of times?

Jan


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