From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Unable to use EFI firmware in Xen ARM guest after 41f8901 Date: Fri, 2 Oct 2015 14:07:03 +0100 Message-ID: <1443791223.11707.99.camel@citrix.com> References: <560D5831.6080403@citrix.com> <1443789792.11707.87.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ard Biesheuvel Cc: Julien Grall , Stefano Stabellini , "edk2-devel@lists.01.org" , Leif Lindholm , "xen-devel@lists.xen.org" , Julien Grall , Heyi Guo List-Id: xen-devel@lists.xenproject.org On Fri, 2015-10-02 at 14:48 +0200, Ard Biesheuvel wrote: > On 2 October 2015 at 14:43, Ian Campbell wrote: > > On Fri, 2015-10-02 at 14:18 +0200, Ard Biesheuvel wrote: > > > Is there any reasonable upper bound to the domU PA space > > > other than what is communicated in the ID registers? > > > > You mean the PASize bits/register? In which case that is it as far as > > the > > guest should be is concerned, yes. > > > > OK. > > As discussed on IRC (#xenarm), the rationale of this approach is that > Xen's stage2 attributes will ultimately override device mappings, so > 1:1 mapping the whole address space cacheable is actually a reasonable > thing to do. And in fact, 4 KB of translation tables for each 512 GB > of address space is probably not such a big deal after all. Well, I'm not going to commit to that always being the case, since its not part of the guest ABI, but given that OVMF would normally be supplied as part of the host rather than the guest if we ever break/change that assumption we do at least have the opportunity to get ovmf fixed/updated around the same time. IOW I suppose this is tolerable. > So I am > inclined to leave things are they are if the proposed patch works. Sure. Ian.