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

Re: [PATCH v3 6/7] x86/dmop: Add XEN_DMOP_enable_ext_dest_id DM op


  • To: Julian Vetter <julian.vetter@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 9 Mar 2026 14:26:09 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • 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=l7n5O3eHZxb0m8XX25UCo/ymu9WkcyBzlfUUnlzR+e0=; b=SwYcl3vsX6lc3NyItOTZfRqRI8YPGO7T8YYIe/aLcMG824v8bHl2Y4erjXRzfZRaWH0375CTx3OiEZ+KJ17/qmCsv/eCTNVUPbKyPeEBTnIqhd3zqO1WU8C47LDyosydPwOHhLOW99d3vqe6RcjK5rsd3fPgYYsIyE2xgTY3roCGUNL4YioQGwbT4jCQ2ZAfFMGjhlt00qDYDBTqTlJLV/7gH4CoHFqb7pqbyjpZIvBmlzZtT7j4VhhGetommWF9xi49fAYk0dwFeqBCrB4E+XJHqK2OPUAIRLv2o7dLe6YRQvpoWYoliS8zSVLuLtv4w2Ys4hrgU+dIQdMMHkGi5g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TtP1QJ7VIkT8vd01GEBRFmexd1GmbKxOds8N2Kulda2UQ8skGGSM8YkZ3v0wI1bcw4/vAQ8F1gSs3Vp7TbLHPXdo34qMgj6WofGRhYiV0rwas3w7zKEePUpHdf+4+mL+yVSpQqDsWk/ZVRJnSi8jqT/SnXEYDjzTiJ2ZxWh9q2InL+0g8yp5f52+lLShpx9nBcsIh6CjDxM+o42cHpNYwZzow3qMYvRb8ylthvYG4O6aeTdvGMNrTda8Ns7nEAbEYhUkXxhO8RnjvEQVoBQ2tskfd/0iDgddrKHbFeAJZ0ILiCfWaLSWaYh4R8F4zqAlYW88rPuVdKErhViqhudWWA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Mon, 09 Mar 2026 13:26:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Mar 09, 2026 at 12:31:03PM +0000, Julian Vetter wrote:
> Xen cannot simply advertise XEN_HVM_CPUID_EXT_DEST_ID to the guest
> without knowing that the device model will handle extended destination
> IDs correctly for passthrough MSIs. A device model that still uses
> XEN_DOMCTL_bind_pt_irq would pass only the low 8 bits of the destination
> ID, misrouting interrupts to vCPUs with APIC IDs greater than 255. So,
> add a DM op XEN_DMOP_enable_ext_dest_id that the device model can call
> during domain setup (before vCPUs are started) to signal that it will
> use XEN_DMOP_bind_pt_msi_irq for all passthrough MSI bindings. When
> called, Xen sets ext_dest_id_enabled in struct hvm_domain, so it's
> visible to the guest via CPUID.

Have you considered whether you could re-use the padding in
XEN_DMOP_create_ioreq_server to signal whether the device model
supports Extended ID parsing?

Also, you might want some negotiation between multiple ioreq servers
on the same domain.  IOW: is multiple ioreq servers are registered
ahead of the domain having finished creation you could level whether
extended ID should be announced.  For ioreqs that are registered after
the domain have started you need to enforce the currently set Extended
ID support.  If the domain is running, and Extended ID is advertised
you must prevent registering any new ioreq that doesn't support
Extended ID.

Thanks, Roger.



 


Rackspace

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