From: "Roger Pau Monné" <roger.pau@citrix.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v5 1/7] x86/msi: passthrough all MSI-X vector ctrl writes to device model
Date: Mon, 29 Apr 2024 10:40:35 +0200 [thread overview]
Message-ID: <Zi9dA0d4ZvI25ksu@macbook> (raw)
In-Reply-To: <3e1150560a41bd567049627d684cd4e754530869.1710342968.git-series.marmarek@invisiblethingslab.com>
On Wed, Mar 13, 2024 at 04:16:06PM +0100, Marek Marczykowski-Górecki wrote:
> QEMU needs to know whether clearing maskbit of a vector is really
> clearing, or was already cleared before. Currently Xen sends only
> clearing that bit to the device model, but not setting it, so QEMU
> cannot detect it. Because of that, QEMU is working this around by
> checking via /dev/mem, but that isn't the proper approach.
>
> Give all necessary information to QEMU by passing all ctrl writes,
> including masking a vector. Advertise the new behavior via
> XENVER_get_features, so QEMU can know it doesn't need to access /dev/mem
> anymore.
>
> While this commit doesn't move the whole maskbit handling to QEMU (as
> discussed on xen-devel as one of the possibilities), it is a necessary
> first step anyway. Including telling QEMU it will get all the required
> information to do so. The actual implementation would need to include:
> - a hypercall for QEMU to control just maskbit (without (re)binding the
> interrupt again
> - a methor for QEMU to tell Xen it will actually do the work
^ method
> Those are not part of this series.
>
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> ---
> I did not added any control to enable/disable this new behavior (as
> Roger have suggested for possible non-QEMU ioreqs). I don't see how the
> new behavior could be problematic for some existing ioreq server (they
> already received writes to those addresses, just not all of them),
> but if that's really necessary, I can probably add a command line option
> to restore previous behavior system-wide.
That's fine I guess, as you say such ioreq servers should already know
how to handle the ranges, and if anything the current behavior of
device models not receiving all accesses is likely the bogus (or
unexpected at least).
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Thanks, Roger.
next prev parent reply other threads:[~2024-04-29 8:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 15:16 [PATCH v5 0/7] MSI-X support with qemu in stubdomain, and other related changes Marek Marczykowski-Górecki
2024-03-13 15:16 ` [PATCH v5 1/7] x86/msi: passthrough all MSI-X vector ctrl writes to device model Marek Marczykowski-Górecki
2024-04-25 10:45 ` Jan Beulich
2024-04-29 8:40 ` Roger Pau Monné [this message]
2024-03-13 15:16 ` [PATCH v5 2/7] x86/msi: Extend per-domain/device warning mechanism Marek Marczykowski-Górecki
2024-04-25 11:25 ` Jan Beulich
2024-03-13 15:16 ` [PATCH v5 3/7] x86/hvm: Allow access to registers on the same page as MSI-X table Marek Marczykowski-Górecki
2024-04-25 11:15 ` Jan Beulich
2024-04-26 15:26 ` Marek Marczykowski-Górecki
2024-04-29 6:37 ` Jan Beulich
2024-03-13 15:16 ` [PATCH v5 4/7] automation: prevent QEMU access to /dev/mem in PCI passthrough tests Marek Marczykowski-Górecki
2024-03-13 15:16 ` [PATCH v5 5/7] automation: switch to a wifi card on ADL system Marek Marczykowski-Górecki
2024-03-13 15:16 ` [PATCH v5 6/7] [DO NOT APPLY] switch to qemu fork Marek Marczykowski-Górecki
2024-03-13 15:16 ` [PATCH v5 7/7] [DO NOT APPLY] switch to alternative artifact repo Marek Marczykowski-Górecki
2024-04-18 14:18 ` [PATCH v5 0/7] MSI-X support with qemu in stubdomain, and other related changes Marek Marczykowski-Górecki
2024-04-18 14:22 ` 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=Zi9dA0d4ZvI25ksu@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=marmarek@invisiblethingslab.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.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.