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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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.

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.

 -George

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