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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 14 Aug 2015, Shannon Zhao wrote:
> On 2015/8/13 18:29, 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.
> 
> If we remove the entry of SPCR table from XSDT table, would it work for
> Dom0 to ignore the uart? And it doesn't need the STAO table?

I don't think that is enough because the very same uart is likely to be
described in the dsdt too. I am pretty sure that we need the STAO.

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