Re: [Xen-devel] (v2) Design proposal for RMRR fix

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2015-01-14 at 15:39 +0000, George Dunlap wrote:
> On 01/14/2015 03:18 PM, Ian Campbell wrote:
> >>> Host BIOSes are generally large compared to the guest BIOS, but with the
> >>> amount of decompression and relocation etc they do I don't know how much
> >>> of them generally remains in the <1MB region.
> >>
> >> Recall the example: (host) RMRR naming E0000-EFFFF, which
> >> overlaps with the init-time guest BIOS image, but doesn't overlap
> >> with its resident part (as long as that doesn't exceed 64k in size).
> > 
> > Right, that means second precondition above doesn't really hold, which
> > is a shame.
> > 
> > In principal it might be possible to have some of the RMRR setup and
> > conflict detection stuff in SeaBIOS rather than hvmloader, and therefore
> > take advantage of the same init-time vs resident distinction, but I
> > suspect that won't lead to an overall design we are happy with, mainly
> > since such things are typically done by hvmloader in a Xen system.
> 
> Actually, I was just thinking about this -- I'm not really sure why we
> do the PCI MMIO stuff in hvmloader at all.  Is there any reason, other
> than the fact that we need to tell Xen about updates to the physical
> address space?  If not, it seems like doing it in SeaBIOS would make a
> lot more sense, rather than having to maintain duplicate functionality
> in hvmloader.

I don't remember exactly, but I think it was because something about the
PCI enumeration required reflecting in the ACPI tables, which hvmloader
also provides. Splitting it up was tricky, that was what I initially
tried when adding SeaBIOS support, it turned into a rats nest.

> Anthony is looking into this, but if SeaBIOS inside KVM is able to
> notify qemu about changes to the memory map, then it seems like teaching
> SeaBIOS how to tell Xen about those changes (or have qemu do it) would
> make a lot of our problems in this area a lot simpler.

SeaBIOS on qemu uses the firmware cfg interface (a bit bashed protocol
over a magic port) to split these responsibilities. I'm not sure of the
exact split but I know that not so long ago responsibility for
constructing the ACPI tables moved from SeaBIOS to qemu (or maybe just a
subset, perhaps someone else knows better).

> For RMRRs, presumably SeaBIOS is already set up to avoid them; so if we
> can just give it an e820 with the RMRRs in it, then everything will just
> fall out of that.

I suppose, my guess would be that any code which would go anywhere near
stuff like is already gated on Xen because hvmloader takes care of it.

Ian.


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