[Xen-devel] gross qemu behavior

["Jan Beulich" <JBeulich@xxxxxxxx>]

Hi,

so while doing all that EPT work I naturally also happened to look more
closely at the EPT table dumps, spotting an odd range of 16 pages
outside any supposedly populated address range. This range only
exists when guest memory doesn't extend past (by default) 0xf0000000
(the start of MMIO, i.e. normally the frame buffer). After spending quite
a bit of time I finally figured that this must be a left over of the Cirrus
VGA ROM, and I would have thought that this

--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1976,6 +1976,9 @@ static int pci_add_option_rom(PCIDevice 
     }
 
     pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
+    memory_region_add_subregion_overlap(pdev->bus->address_space_mem,
+                                        pdev->rom.ram_addr, &pdev->rom, 1);
+    memory_region_del_subregion(pdev->bus->address_space_mem, &pdev->rom);
 
     return 0;
 }

should fix it. It does appear to work as far generic qemu is concerned,
but once looking at the Xen backend I had to conclude that this just
can't work: For one, xen_add_to_physmap() and
xen_remove_from_physmap() are _documented_ (in a comment) to
only be capable of a single region (VRAM). And the latter - even worse -
is implemented with a call to xc_domain_add_to_physmap(), completely
contrary to its name.

Instrumenting xen_region_{add,del}(), I can see that all regions get
properly reported to the Xen backend, just that it doesn't handle them
(this is with above patch in place):

xra(fee00000,100000)
xra(fec00000,1000)
xra(fed00000,400)
xra(80000000,10000)
xrd(80000000,10000)
xra(f0000000,800000)
xra(f1000000,400000)
xra(f2000000,1000000)
xra(f3010000,4000)
xra(f3014000,1000)
xra(f3015000,3000)
xra(f3018000,1000)
xra(f3000000,10000)
xrd(f3000000,10000)
xrd(f0000000,800000)
xra(f0000000,800000)
mapping vram to f0000000 - f0800000

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.

Jan


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