[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Wed, 2015-01-14 at 15:07 +0000, Jan Beulich wrote:
> >>> On 14.01.15 at 13:17, <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Wed, 2015-01-14 at 08:06 +0000, Tian, Kevin wrote:
> >> - RMRRs conflicting with guest BIOS in <1MB area, as an example of 
> >> hard conflicts
> > 
> > OOI what is the (estimated) probability of such an RMRR existing which
> > doesn't already conflict with the real host BIOS?
> 
> Surely the host BIOS will know to place the RMRRs outside its BIOS
> image.

Yes, my point was that if this were the case (as you'd expect) and the
virtual BIOS was smaller than the physical one, then the probability of
an RMRR conflicting with the virtual BIOS would be low.

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

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.