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

[Christoffer Dall <christoffer.dall@xxxxxxxxxx>]

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.

-Christoffer

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