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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2015-01-14 at 18:14 +0000, George Dunlap wrote:
> On 01/14/2015 03:43 PM, Ian Campbell wrote:
> > 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.
> 
> Blah. :-(

It *might* have been more complicated because I was also trying to keep
ROMBIOS+qemu-trad doing something sensible and worrying about code
duplication, plus the whole seabios thing was pretty new to me at the
time as well.

It probably wouldn't be a waste of time for someone for spend say 1/2 a
day taking another poke at it (modulo what you said below perhaps making
it a little moot).

> >> 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.
> 
> Yes, that's in fact what happens (I'm pretty sure in the MMIO placement
> code it has an "if (xen) return;" at the top); I was trying to envision
> a future where this was all rationalized and de-duplicated.
> 
> And for the record, Anthony has just looked into what happens with the
> MMIO hole on KVM, and apparently SeaBIOS is just given either a 0.5 or
> 1G hole, and if it can't fit everything, it calls panic().  (i.e.,
> there's no way for SeaBIOS to make the hole bigger on KVM either).

It's possible that solving this for both would gain some traction with
upstreams, although whether our preferred solution would be a good fit
for kvm I dunno, since we have different concepts of who is the ultimate
authority on the address space.

> So it looks like the path to a rational system is more difficult than I
> had initially hoped.

True.

Ian.


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