Re: [Xen-devel] Xen 4.3 development update

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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