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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.15 at 16:39, <george.dunlap@xxxxxxxxxxxxx> 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.

Fully agreed - this really is the BIOSes job. The only caveat being
that for as long as we support it, things still need to continue to
work with qemu-trad.

> 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.
> 
> 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.

Not sure - building the E820 table is also the BIOSes job, as is (on
real hardware) placing the RMRRs. That latter thing is what is
entirely different for our case - BIOS/hvmloader can't pick where
they want the RMRRs, they have to live with where they are.

Jan


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