qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	Paul Durrant <paul@xen.org>,
	"open list:X86 Xen CPUs" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/2] Do not access /dev/mem in MSI-X PCI passthrough on Xen
Date: Mon, 14 Nov 2022 23:44:17 +0100	[thread overview]
Message-ID: <Y3LEwV6kqqZ/pyy1@mail-itl> (raw)
In-Reply-To: <5f2b496a-f1dc-aa45-9600-aa9e5bbede8e@citrix.com>

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

On Mon, Nov 14, 2022 at 07:39:48PM +0000, Andrew Cooper wrote:
> On 14/11/2022 19:20, Marek Marczykowski-Górecki wrote:
> > The /dev/mem is used for two purposes:
> >  - reading PCI_MSIX_ENTRY_CTRL_MASKBIT
> >  - reading Pending Bit Array (PBA)
> >
> > The first one was originally done because when Xen did not send all
> > vector ctrl writes to the device model, so QEMU might have outdated old
> > register value. This has been changed in Xen, so QEMU can now use its
> > cached value of the register instead.

I should have noted that "has been changed in Xen" isn't fully accurate
(yet). It refers to this patch:
https://lore.kernel.org/xen-devel/20221114192100.1539267-2-marmarek@invisiblethingslab.com/T/#u

> > The Pending Bit Array (PBA) handling is for the case where it lives on
> > the same page as the MSI-X table itself. Xen has been extended to handle
> > this case too (as well as other registers that may live on those pages),
> > so QEMU handling is not necessary anymore.
> >
> > Removing /dev/mem access is useful to work within stubdomain, and
> > necessary when dom0 kernel runs in lockdown mode.
> >
> > Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> 
> The commit message ought to go further.  Using /dev/mem like this is
> buggy anyway, because it is trapped and emulated by Xen in whatever
> context Qemu is running.  Qemu cannot get the actual hardware value, and
> even if it could, it would be racy with transient operations needing to
> mask the vector.
> 
> i.e. it's not just nice-to-remote - it's fixing real corner cases.

Good point, I'll extend it.
But for this to work, the Xen patch needs to go in first (which won't
happen for 4.17). And also, upstream QEMU probably needs some way to
detect whether Xen has the change or not - to work with older versions
too.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-11-14 23:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-14 19:20 [PATCH 1/2] hw/xen/xen_pt: Call default handler only if no custom one is set Marek Marczykowski-Górecki
2022-11-14 19:20 ` [PATCH 2/2] Do not access /dev/mem in MSI-X PCI passthrough on Xen Marek Marczykowski-Górecki
2022-11-14 19:39   ` Andrew Cooper
2022-11-14 22:44     ` Marek Marczykowski-Górecki [this message]
2022-11-15  8:14   ` Jan Beulich
2022-11-15 11:38     ` Marek Marczykowski-Górecki
2022-11-15 14:05       ` Jan Beulich
2022-11-16 19:15   ` Jason Andryuk
2022-11-16 21:40     ` Marek Marczykowski-Górecki
2022-11-17  3:34       ` Marek Marczykowski-Górecki
2022-11-17  8:04         ` Jan Beulich
2022-11-17 11:15           ` Marek Marczykowski-Górecki
2022-11-17 17:29         ` Jason Andryuk
2022-11-22 17:12 ` [PATCH 1/2] hw/xen/xen_pt: Call default handler only if no custom one is set Anthony PERARD via
2023-09-26 23:25   ` Marek Marczykowski-Górecki

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=Y3LEwV6kqqZ/pyy1@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=paul@xen.org \
    --cc=qemu-devel@nongnu.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).