Re: [PATCH v6 5/5] ARM: ITS: Expose ITS in the MADT table

[Julien Grall <julien.grall@linaro.org>]

Hi,

On 10/10/2017 21:07, Stefano Stabellini wrote:
> CC'ing Jan and Andrew, just in case they disagree on this.
>
> On Tue, 10 Oct 2017, Julien Grall wrote:
>>>> +unsigned long gicv3_its_make_hwdom_madt(const struct domain *d, void
>>>> *base_ptr)
>>>> +{
>>>> +    unsigned int i;
>>>> +    void *fw_its;
>>>> +    struct acpi_madt_generic_translator *hwdom_its;
>>>> +
>>>> +    hwdom_its = base_ptr;
>>>> +
>>>> +    for ( i = 0; i < vgic_v3_its_count(d); i++ )
>>>> +    {
>>>> +        fw_its =
>>>> acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
>>>> +                                           i);
>>>> +        memcpy(hwdom_its, fw_its, sizeof(struct
>>>> acpi_madt_generic_translator));
>>>
>>> I think we are supposed to use ACPI_MEMCPY for this kind of operations.
>>> If that's OK for you, I'll fix on commit.
>>
>> I don't think we should use ACPI_MEMCPY. The macro is here because acpica (our
>> drivers/acpi) is meant to be OS-agnostic. So you need a way to tell how your
>> OS copies memory.
>>
>> I had a look on the usage of ACPI_MEMCPY, it seems that only the arch/arm and
>> drivers/acpi is using it. This seem to confirm that probably we used it by
>> mistake in the Arm code.
>
> It looks like you are right, ACPI_MEMCPY does not make sense in Xen
> code outside of drivers/acpi.
>
> Consistency is important, so if we are not going to use ACPI_MEMCPY, then
> I'll write a patch (or I'll take a patch if you volunteer in writing it)
> to s/ACPI_MEMCPY/memcpy/g everywhere under arch/arm. The worst we could
> end up with is a mixed environment.

Feel free to write a patch, but I don't think you should block this 
series for that.

Cheers,

-- 
Julien Grall

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