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
