[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 01/15] xen: Clean up asm-generic/device.h


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Alejandro Vallejo <agarciav@xxxxxxx>
  • Date: Fri, 6 Jun 2025 11:55:30 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k3sq9ZSeuYfZ6qSVtrYHI1s8YoEhXWX1JYfCFAdlAOY=; b=sAp1COQCz4TJLgLz1mb8fCVT19SOuQuyeZxnuyd7OU1sp/VXMX/CTQ2llXkf5cgzFG5jv5ByamLskyfbCQFUUsFGag9KxuTNLnYBRnQQJzHUewXia4KuYg/sQmBZdI/k1ceqnpdt1VWLcgqALWQM9GmkTlubXONOA+I2iCQXwMaewt1NPePncFKeivzQ973YaCljWe5GCBItrixd8/gY7WR8n+ecnqQ/g5FZz1r+2NAS7XWm1RK3Yrd9M4Gh52Gx45bynalv9odpULDmXwoP2Wei7vhGR5iSMwLs4r9jJhT4wRpHz+cSz5Vprq5IbuQSJFRW3fo8XqdsjIce2rjQAw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eQGd5PVRmF0qnee5IcahzymV9IsiSxcaUDaROc0EHMbtNULsHIQuXXVsATwB1OF3f5XBxLz7yh+Ls73L55fiXPC9fq73VgztdUJ+l0wxmwpUktEowWiGbaZQGN63vSlr5HJUTkzjB30+TiIpGELaB/thCFAEJKmG0EyJAfZzhP/qP30WfEJS/KZhVaL5RHAqLCtnsA+b/vRSOpQIItsIOstaMhrzvaJce7BjCwtfnzPi/MTVFyksMqlue6/3el5NOC1icR5KzJQXlC63qym9s7IDkWwEfbxcxOZTEOZuI/ftV4KdmAWlNwLNIeXao2NGo/PCVO633qUXYB8ApOikbA==
  • Cc: Alistair Francis <alistair.francis@xxxxxxx>, Bob Eshleman <bobbyeshleman@xxxxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>, "Oleksii Kurochko" <oleksii.kurochko@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 06 Jun 2025 09:55:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri Jun 6, 2025 at 8:51 AM CEST, Jan Beulich wrote:
> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>> --- a/xen/include/asm-generic/device.h
>> +++ b/xen/include/asm-generic/device.h
>> @@ -1,14 +1,20 @@
>>  /* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * This header helps DTB-based architectures abstract away where a 
>> particular
>> + * device came from, be it the DTB itself or enumerated on a PCI bus.
>> + */
>>  #ifndef __ASM_GENERIC_DEVICE_H__
>>  #define __ASM_GENERIC_DEVICE_H__
>>  
>> +#ifndef CONFIG_HAS_DEVICE_TREE
>> +#error "Header for exclusive use of DTB-based architectures"
>> +#endif
>> +
>>  #include <xen/stdbool.h>
>>  
>>  enum device_type
>>  {
>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>      DEV_DT,
>> -#endif
>>      DEV_PCI
>>  };
>
> My objection to these changes remains; as a generic header it ought to be what
> that attribute says - generic.
>
> Jan

It is generic for any architecture where platform DTs exist (that is, anything
but x86).

As the commit message states, these guards are useless, provide no functionality
and create the fiction that somehow this header is still relevant on an
architecture where only PCI is available. And that's just not true. x86 being
the sole architecture without DTs actively overrides it, and relies on device_t
(defined as struct device here) to be a "struct pci_dev" instead in
x86/include/asm/device.h, with dev_to_pci() and pci_to_dev() being irrelevant
because device_t* and struct pci_dev* are identical types in x86. Removing that
override header is not just a matter of performance. All the IOMMU ops are
referencing device_t, while the drivers are assuming pci_dev, so all IOMMU
code breaks immediately when x86 tries to use this.

To be perfectly clear, this patch isn't strictly required to do DT unflattening
on x86. But it's a piece of arm tech debt that Xen is better off without.

Cheers,
Alejandro



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.