[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/3] x86/msi: passthrough all MSI-X vector ctrl writes to device model
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Mon, 27 Mar 2023 17:42:29 +0200
- 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=arcselector9901; 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=bHS6jqjRW5IebXgDbZe0PUK5VFUcNMPbWPZWJDB03eU=; b=hgZQp8oLpXP2k2LhWyZt6eP1y5rj5ysbgr3nIuR1rXaNwYw5JRqXgnVMK6dpUk7HSQ6CwQS++iMWu/lE7q3231lBsZebBkWVZzGiBMkhWdlhocY8CJwPxJzq8lgilt1LoLAWwM5XII7SRourrbu+9mX7ZgathbOFw9pE6KT+i11GTBwaoXhDNuAHAXuMM58+4IUTd+POsLOcidXE3xACF5ON9XIJb4BIQwC8cAZHjcWRmiNVWtYP2UOJW1WYPLXpwtH2srL7jNgQ9EVVJXtbErqQdmJk5/HT2hDJO5ZTAIGNBdpcDXjLgmw0QY3Ebdl1lcp0rJi4kKZJUDC3pwYmQQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aKPGZ0q86DjwscCMBxySh2e5l1DnUqKHBYhCj+pZEMxkBECLIHTPsUuF7vw1QgzrYKy4PReR+W50/DF5USoC3veXGkXk/OgNglAN1GpwH25zC3HYj96Fuzk7d1WekSXmonbht+zuBUBF35SPeebgHrhAYy1Dr4n2PFFPb8WEm5Y1umLSPvoJ1lcob+julPj4LENC/1qGWMA3lw124N4YxKmAPM9gsVuP2vM2ds5cNxqAGYNN/5zj6Fs0a5Hjz/HG7JN/agn3UyMHmEC0XJ/R9mx5HJ//JAhfNaOt/yE4EAuWIZgSoa1iFystlm+TLDl6U/86NKg9DmyhrtM0UEMCbA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Jason Andryuk <jandryuk@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 27 Mar 2023 15:42:48 +0000
- Ironport-data: A9a23:2HFAyq5KfOh0KoWNCXHXbgxRtOXGchMFZxGqfqrLsTDasY5as4F+v mMYXmyCbq7ZZ2GgcogiO4q/9U4AsMDczNMxTlQ9rn81Hi5G8cbLO4+Ufxz6V8+wwm8vb2o8t plDNYOQRCwQZiWBzvt4GuG59RGQ7YnRGvynTraCYnsrLeNdYH9JoQp5nOIkiZJfj9G8Agec0 fv/uMSaM1K+s9JOGjt8B5mr9VU+7JwehBtC5gZlPasR4weE/5UoJMl3yZ+ZfiOQrrZ8RoZWd 86bpJml82XQ+QsaC9/Nut4XpWVTH9Y+lSDX4pZnc/DKbipq/0Te4Y5iXBYoUm9Fii3hojxE4 I4lWapc6+seFvakdOw1C3G0GszlVEFM0OevzXOX6aR/w6BaGpdFLjoH4EweZOUlFuhL7W5m5 dwBLCA2bj251vPt/ZeqY/tLnoN/I5y+VG8fkikIITDxK98DGMmGaYOaoNhS0XE3m9xEGuvYa 4wBcz1zYR/cYhpJfFAKFJY5m+TujX76G9FagAvN+exrvC6OnEoojumF3Nn9I7RmQe1PmUmVv CTe9nnRCRAGLt2PjzGC9xpAg8eWxXmqBN5LRODQGvhCrXuf72FKE0Yqa0qKhNq/jF+ddcxCJ BlBksYphe1onKCxdfH/VRClpH+PvjYHRsFdVeY97Wml2qfSpgqUGGUAZjpAc8A98t87QyQw0 V2ElM+vAiZg2JWXQHSR7KaJrhu9PCEUKSkJYipsZRQBy8nupsc0lB2nZtNqCqu8lND2MTD23 TGRrSI6iqkTjMgEzKGy9xbMhDfEm3TSZgs85wGSVGT16Ap8Pdehf9bxtwmd6utcJoGESFXHp GIDh8WV8OEJC9eKiTCJR+IOWrqu4p5pLQHhvLKmJLF5nxzFxpJpVdk4DO1WTKuxDvs5RA==
- Ironport-hdrordr: A9a23:7X132qpfkowDx4lJiSYolF8aV5rseYIsimQD101hICG8cqSj5q aTdZUgtSMc7Qx7ZJhOo7G90cW7MBbhHP1OkPAs1NWZLXHbUQKTRekMg7cKqweQYBEWndQtsZ uIHZIOb+HYPBxWt+u/xi+SeuxN/DCAysqVrNab9VtWCStNTI5BwTtDIju6NGozfiV6bKBJd6 a0145Jpz+tY3QFYt7TPBQ4duLevcDMkJ78QTNuPW9E1DWz
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Mon, Mar 27, 2023 at 05:32:01PM +0200, Jan Beulich wrote:
> On 27.03.2023 12:12, Roger Pau Monné wrote:
> > On Sat, Mar 25, 2023 at 03:49:22AM +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. This does include forwarding also writes
> >> that did not change the value, but as tested on both Linux (6.1.12) and
> >> Windows (10 pro), they don't do excessive writes of unchanged values
> >> (Windows seems to clear maskbit in some cases twice, but not more).
> >
> > Since we passthrough all the accesses to the device model, is the
> > handling in Xen still required?
>
> "All accesses" isn't really correct; aiui even after this change it's only
> "all writes". We still "accelerate" reading from the first 3 table entries
> (whether or not that's [still] useful in this shape is a separate question).
> Plus we need to invoke guest_mask_msi_irq() as necessary, and I don't think
> we should make ourselves dependent upon qemu communicating the necessary
> info back to us, when that's necessary for the correctness of Xen's internal
> interrupt handling. (That's further leaving aside the performance aspect of
> handing off to qemu just for it to pass data back to us.)
The call to guest_mask_msi_irq() is a result of a guest action, I'm
failing to see how that's necessary for the correctness of Xen's
internal interrupt handling. In my proposed model QEMU won't be
allowed direct access to the physical MSIX entry mask bits, and would
instead use an hypercall to mask/unmask MSIX entries (and thus
guest_mask_msi_irq() would be called as appropriate).
Thanks, Roger.
|
