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

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2015-08-13 at 00:41 -0600, Jan Beulich wrote:
> > 
> > Nonetheless, we still have to copy some table in Xen in order to modify
> > them and/or new one. I have in mind the FADT table to set the hypervisor
> > field and hiding the hypervisor specific data (GIC hyp, timer hyp...) to
> > avoid the kernel thinks there is hyp mode available.
> 
> "Have to"? Or rather "would like to"? As said in another reply to
> Shannon, I didn't see any rationale spelled out for this fundamental
> difference to x86.

I think the fundamental difference is that h/w virt features are not
(always) "discoverable" through h/w interfaces on ARM whereas they are
visible in e.g. cpuid on x86 and not described in ACPI (x86 is only just
gaining hardware support for virtualised interrupts so perhaps this will
change? I think it doesn't have any hypervisor dedicated timer sources).

So on ARM the firmware tables contain things like the additional
virtualisation register regions in the interrupt controller description and
the hypervisor timer interrupt in the timer block description. So we would
like to hide these from dom0.

Perhaps instead we should teach dom0 to notice that it was launched in
Kernel mode rather than Hyp mode (which is detectable) and therefore ignore
these unusable resources. Now you mention it that does sound sensible and I
imagine is even already (close to) true for a Linux kernel to handle e.g.
older firmware with newer device tree.

The other reason for modification is to hide the Xen console device (i.e.
one UART) from the dom0 kernel, since it is unusable. How does that work on
x86? Do you just not bother and you expect the admin to arrange the
configuration to work or is there some other trick?

BTW, IIRC x86 does modify at least one ACPI table which is the DMAR (I
think), to hide the IOMMU from the guest? That's another table we would
want to frob on ARM I think (or it's equivalent, which I think is IORT).

Ian.