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

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.

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.

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.

In terms of code we could share in Linux between Xen x86 and Xen ARM
regarding dealing with ACPI info we want to ignore, unfortunately there
isn't much of it, because we are mostly talking about new ARM specific
tables here (GIC, arch_timer, etc).

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