[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.3 development update
On Tue, 2013-06-11 at 13:11 +0100, George Dunlap wrote: > On Mon, Jun 10, 2013 at 5:04 PM, George Dunlap > <George.Dunlap@xxxxxxxxxxxxx> wrote: > > * qemu-upstream MMIO hole issue > > > http://lists.xen.org/archives/html/xen-devel/2013-03/msg00559.html > > > "You can reproduce it when a VM has a big pci hole size (such as > > 512MB), e.g. create a VM with a virtual device which has a 512MB > > pci BAR." > > priority: high > > status: Original fix broken; investigating proper fix > > priority: blocker (?) > > Any chance someone could spend a bit of time digging into SeaBIOS / > qemu to see if: > 1. SeaBIOS has any logic for querying the PCI space and changing the > size of the PCI hole > 2. If SeaBIOS can do this when running on qemu, and if so, why it's not > working? Under QEMU SeaBIOS will enable a bunch of extra magic code which talks to qemu to figure this stuff out and construct e.g. an e820. Under Xen the e820 is created by hvmloader and passed to SeaBIOS which doesn't further mess with it. This is similar to how I understand things work on real hardware -- coreboot brings up the platform and takes care of all this stuff before launching SeaBIOS to provide a "traditional" BIOS like layout. Coreboot supplies the e820 (or some precursor which SeaBIOS then turns into an actual e820). I'd have thought the code in tools/firmware/hvmloader/pci.c would be the bit which would take care of this for us. It sets pci_mem_start/end which are then consumed by acpi/build.c into the ACPI info struct (shared information with the AML code). I don't know enough AML to locate the code which actually responds to this bit though. I'm a bit surprised that pci_mem_start is not referenced in hvmloader/e820.c though. Or maybe this issue isn't related to the e820 hole but some other representation of it? (I've not really been following all that closely...) I'm wondering how this works for the traditional QEMU + ROMBIOS combo... > This document seems to make it clear that on real hardware the BIOS is > expected to resize the PCI hole based on the available devices; for > example, "Installing PCI expansion cards may also increase the size of > the hole. The impact will depend on the amount of Memory Mapped I/O > (MMIO) space the PCI card(s) require." > > http://techfiles.de/dmelanchthon/files/memory_hole.pdf > > If SeaBIOS runs on real hardware, it should be able to do the same thing. I think this is coreboot's job on real h/w, but I'm not 100% sure. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |