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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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