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, Jan Beulich wrote:
> >>> On 13.08.15 at 11:43, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Thu, 13 Aug 2015, Jan Beulich wrote:
> >> >>> On 12.08.15 at 18:18, <julien.grall@xxxxxxxxxx> wrote:
> >> > On 12/08/15 16:58, Jan Beulich wrote:
> >> >>>>> On 12.08.15 at 17:51, <christoffer.dall@xxxxxxxxxx> wrote:
> >> >>> On Wed, Aug 12, 2015 at 5:45 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >> >>>>>>> On 07.08.15 at 04:11, <zhaoshenglong@xxxxxxxxxx> wrote:
> >> >>>>> All these tables will be copied to Dom0 memory except that the reused
> >> >>>>> tables(DSDT, SPCR, etc) will be mapped to Dom0.
> >> >>>>
> >> >>>> Which again seems odd - such tables should be considered MMIO
> >> >>>> (despite living in RAM), and hence not be part of Dom0's memory
> >> >>>> assignment.
> >> >>>>
> >> >>> not sure if this applies to the context of your comment, but we had
> >> >>> issues before when trying to deal with this data as device memory
> >> >>> (MMIO), because ARM doesn't allow unaligned accesses etc. on device
> >> >>> memory, and so Dom0 would crash at memory abort exceptions during
> >> >>> boot, so this really does have to be mapped as RAM to Dom0.  If you
> >> >>> meant some internal Xen bookkeeping thing, then just ignore me.
> >> >> 
> >> >> Hmm, how would native Linux avoid such unaligned accesses then?
> >> > 
> >> > ACPI table are living on RAM on ARM. So there is no issue with Linux
> >> > baremetal.
> >> 
> >> I'm sure our interpretation of the meaning of RAM here differs:
> >> While from a physical perspective the tables live in RAM too on
> >> x86, from a memory map perspective they don't. And since iirc
> >> ACPI implies UEFI, and since UEFI has special memory types
> >> for such tables (to prevent the OS from using the space as
> >> normal memory), I can't believe this to be different under ARM.
> >> 
> >> > The "problem" is from Xen where we are mapping memory region with Device
> >> > attribute. This is because until now we never had a reason to directly
> >> > map other thing than MMIO to the domain.
> >> > 
> >> > This could be fixed by adding new helper in Xen to directly map RAM 
> >> > region.
> >> 
> >> Which would seem to be the correct route.
> >> 
> >> > 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.
> > 
> > Just because it was done this way before, it doesn't mean that it is the
> > right way of doing it.
> 
> Correct. Which is why I'm not saying outright "no" but asking for
> justification.
> 
> > I think is bad design to expose the presence of certain functionalities
> > in ACPI tables and then expect that the Dom0 kernel won't use them.
> > ACPI tables should describe only and all the hardware which is exposed
> > to Dom0. Anything else is a mistake.
> 
> That depends on the perspective you take: Especially for a PV
> Dom0 it is quite reasonable for the kernel to be aware of certain
> implications from running under a (or the) hypervisor it knows of.
> I agree that the perspective may shift when it comes to HVM-like
> Dom0 (albeit in the spectrum I'd rather see ARM near PVH, which
> again is supposed to be aware).

PVH has always been the wrong analogy for ARM guests. Guest kernels boot
following native boot paths. They don't require emulation because the
ARM architecture is much more flexible and legacy free compared to x86,
not because we instructed the kernel to ignore certain pieces of
hardware. So they are like PV on HVM without any need for QEMU because
there is nothing to emulate. Maybe the right analogy is HVMLite.


> > 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.

It is not just about the GIC Hyp functionalities.


> > I would rather teach Xen to fix the tables now, than later try teach
> > every possible Dom0 kernel (Linux, FreeBSD, etc) to ignore a set of info
> > which are wrong but still passed to them anyway. Moreover the list of
> > things to ignore can change over time. It is just a bad ABI to maintain.
> 
> I don't think there's a clear advantage to teaching Xen of new
> tables to hide over teaching Dom0 of new tables to ignore - it
> much depends on release cycles and such which one would be
> more beneficial.

There are a couple of very obvious advantages:

- there is one Xen, there are many Dom0 kernels
- if Xen changes ACPI tables, Dom0 won't be surprised by the fact that
actually they don't match the hardware. Keep in mind that we don't have
10 years of PV history on ARM. People still think of this as confusing
and counter-intuitive.

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