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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

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

Jan

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