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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Wednesday, January 14, 2015 11:08 PM
> 
> >>> 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.
> 
> > 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).
> 

such RMRR could be in resident part of host BIOS. Here is one example how
such a reserved region is used to support legacy keyboard emulation for 
USB keyboard. Actually a SMI handler is triggered when a 8042 controller
driver accesses legacy keyboard resource (e.g. 60h/64h), and then SMI
handler will access the reserved region which holds meaningful data 
from the USB controller. Host BIOS can allocate such page in any place
where it thinks appropriate, in E0000-EFFFF, in F0000-FFFFF, or in higher
end RAM. so strictly speaking it could be a hard conflict with guest BIOS
though if we know all the information some conflict may be avoided like 
Jan mentioned.

Thanks
Kevin

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