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

[Julien Grall <julien.grall@citrix.com>]

On 12/08/15 16:58, Jan Beulich wrote:
>>>> On 12.08.15 at 17:51, <christoffer.dall@linaro.org> wrote:
>> On Wed, Aug 12, 2015 at 5:45 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 07.08.15 at 04:11, <zhaoshenglong@huawei.com> 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.

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.

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.

Regards,

-- 
Julien Grall