From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Design doc of adding ACPI support for arm64 on Xen - version 2 Date: Thu, 13 Aug 2015 11:34:54 +0100 Message-ID: <1439462094.23981.74.camel@citrix.com> References: <55C413D5.7000709@huawei.com> <55CB861F020000780009A3E9@prv-mh.provo.novell.com> <55CB895E020000780009A462@prv-mh.provo.novell.com> <55CB71E1.8040309@citrix.com> <55CC582D020000780009A712@prv-mh.provo.novell.com> <55CC87A6020000780009A946@prv-mh.provo.novell.com> <1439461339.23981.64.camel@citrix.com> <20150813102929.GB19874@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150813102929.GB19874@cbox> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Christoffer Dall Cc: Hangaohuai , Stefano Stabellini , "Huangpeng (Peter)" , xen-devel , Julien Grall , Stefano Stabellini , Shannon Zhao , Jan Beulich , Shannon Zhao , ParthDixit List-Id: xen-devel@lists.xenproject.org On Thu, 2015-08-13 at 12:29 +0200, Christoffer Dall wrote: > On Thu, Aug 13, 2015 at 11:22:19AM +0100, Ian Campbell wrote: > > On Thu, 2015-08-13 at 11:13 +0100, Stefano Stabellini wrote: > > > > > > > > For example it is only natural for the kernel to try to use the > > > > > GIC > > > > > hyp > > > > > functionalities if they are described, while actually they are > > > > > not > > > > > emulated by Xen at all. > > > > > > > > See Ian's earlier reply: It can also be considered natural for it > > > > to > > > > be aware that when run in EL2 to not use EL1 functionality. > > > > NB EL2 == Hyp and EL1 == Kernel, so it's the other way round, FWIW. > > > > > It is not just about the GIC Hyp functionalities. > > > > What else is there which is not subject to this logic? Timers are too, > > it > > even applies to IOMMU's which have both stage1 and stage2 bits. > > > > BTW, I think kernels _already_ need to deal with a lot of this because > > in > > reality nobody modifies the DTB when they use a firmware which launches > > the > > kernel in EL1. IOW I think the kernel is already aware of which > > resources > > can be used by which privilege level. > > > Yes, for resources specific to EL2 I believe that is indeed the case > (the GIC driver doesn't look at the hypervisor control register address, > and KVM does not even get that far if you're not booted in EL2, and the > timer only uses the virtual timer if not booted in EL2 - we never > attempt to use the hyp timer until Marc's VHE patches land, but they > also depend on being booted in hyp mode). Right, and I think that's almost always going to be the case by virtue of the architecture. You can't use these resources from EL1 (however you got there) so you need checks. > However, what about for other resources? Having code somewhere that > says "hide this random piece of hardware if you're Xen dom0" sounds > awful to me. I know it's only the serial port right now, but still. Right, that's the only bit I'm aware of that I'm not sure about, which is why I was curious how x86 managed it (I've seen but not digested Jan's answer). At least this has the virtue of being an extra table, and tagging on a new one of those has more limited impact on the tables I think. Ian.