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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

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