Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 2

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 13 Aug 2015, 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).
>
> 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.

I completely agree. Non-EL2 specific resources should defenitely be
removed. I can see that EL2 stuff could be left there, but I think that
removing it now would avoid us trouble in the future.

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