From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: (v2) Design proposal for RMRR fix Date: Wed, 14 Jan 2015 15:43:18 +0000 Message-ID: <1421250198.19103.288.camel@citrix.com> References: <54B3AE8802000078000539B7@mail.emea.novell.com> <54B515E6020000780005444A@mail.emea.novell.com> <54B54D48020000780005473E@mail.emea.novell.com> <54B540AA.1010905@eu.citrix.com> <1421237878.19103.244.camel@citrix.com> <54B6944F0200007800054F4E@mail.emea.novell.com> <1421248735.19103.281.camel@citrix.com> <54B68D95.2080802@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B68D95.2080802@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Kevin Tian , "wei.liu2@citrix.com" , "stefano.stabellini@eu.citrix.com" , "ian.jackson@eu.citrix.com" , "tim@xen.org" , "xen-devel@lists.xen.org" , Jan Beulich , Yang Z Zhang , Tiejun Chen List-Id: xen-devel@lists.xenproject.org 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. > 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. Ian.