All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Julian Vetter <julian.vetter@vates.tech>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>, Julien Grall <julien@xen.org>
Subject: Re: [PATCH v3 6/7] x86/dmop: Add XEN_DMOP_enable_ext_dest_id DM op
Date: Mon, 9 Mar 2026 14:26:09 +0100	[thread overview]
Message-ID: <aa7KcQQoc3-HwlcE@macbook.local> (raw)
In-Reply-To: <20260309123055.880050-6-julian.vetter@vates.tech>

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.


  reply	other threads:[~2026-03-09 13:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 12:31 [PATCH v3 1/7] x86/vioapic: Add ioapic_check() to validate IO-APIC state before restore Julian Vetter
2026-03-09 12:31 ` [PATCH v3 2/7] x86/msi: Define extended destination ID masks and IO-APIC RTE fields Julian Vetter
2026-03-10 17:09   ` Jan Beulich
2026-03-11 10:15   ` Roger Pau Monné
2026-03-09 12:31 ` [PATCH v3 4/7] x86/passthrough: Use extended destination ID in PT MSI bind/unbind Julian Vetter
2026-03-11 15:30   ` Jan Beulich
2026-03-09 12:31 ` [PATCH v3 3/7] x86/hvm: Support extended destination IDs in virtual MSI and IO-APIC Julian Vetter
2026-03-11 15:27   ` Jan Beulich
2026-03-12 11:15     ` Jan Beulich
2026-03-16 15:06       ` Julian Vetter
2026-03-19  9:02         ` Jan Beulich
2026-03-09 12:31 ` [PATCH v3 6/7] x86/dmop: Add XEN_DMOP_enable_ext_dest_id DM op Julian Vetter
2026-03-09 13:26   ` Roger Pau Monné [this message]
2026-03-17 10:22     ` Julian Vetter
2026-03-25 10:58       ` Roger Pau Monné
2026-03-12 11:18   ` Jan Beulich
2026-03-09 12:31 ` [PATCH v3 7/7] x86/cpuid: Advertise XEN_HVM_CPUID_EXT_DEST_ID when device model opts in Julian Vetter
2026-03-09 12:31 ` [PATCH v3 5/7] x86/dmop: Add XEN_DMOP_{bind,unbind}_pt_msi_irq DM ops Julian Vetter
2026-03-09 13:38   ` Roger Pau Monné
2026-03-11 16:04   ` Jan Beulich
2026-03-12 11:53     ` Jan Beulich
2026-03-12 11:30   ` Jan Beulich
2026-03-10 16:55 ` [PATCH v3 1/7] x86/vioapic: Add ioapic_check() to validate IO-APIC state before restore Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa7KcQQoc3-HwlcE@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julian.vetter@vates.tech \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.