All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Robin Voetter <robin@streamhpc.com>
Cc: mst@redhat.com, marcel.apfelbaum@gmail.com,
	qemu-devel@nongnu.org, clg@redhat.com
Subject: Re: [RFC PATCH v2 0/4] vfio/pci: Atomic Ops completer support
Date: Wed, 31 May 2023 16:24:46 -0600	[thread overview]
Message-ID: <20230531162446.2bc9a26c.alex.williamson@redhat.com> (raw)
In-Reply-To: <4301d6f4-a394-02e3-4773-823976b2e593@streamhpc.com>

On Wed, 31 May 2023 23:55:41 +0200
Robin Voetter <robin@streamhpc.com> wrote:

> Hi Alex,
> 
> Thanks for taking the time to implement support for Atomic Op completer
> support properly :). I have tested out these patches and the kernel
> patch, and apart from a minor issue with patch 2 everything works fine;

Yes, Cedric noted the extra semicolon as well, I'm about to post that
patch as non-RFC since it has no dependencies on anything else.

> ROCm programs that use device->host atomic operations work properly.

Great, thanks for testing!

> Something that I have been thinking about, are there any implications
> involved with enabling this feature automatically with no possibility of
> turning it off? I have no use case for that, though, and I cant really
> think of a reason other than preventing the guest from finding out
> hardware details about the host.

Not sure I follow, are you suggesting that Atomic Ops completion
support is proactively enabled in the VM to match the host, regardless
of attached assigned devices?  An obvious problem there is migration.
If I start a VM on a host with Atomic Ops support and want to migrate
to a host without Atomic Ops support, config space of the root ports is
now different and the migration fails.  QEMU would also require
elevated privileges to read config space to determine the host support,
and then what does it do if only some of the PCIe hierarchy supports
Atomic Ops.

Policy decisions like that are generally left to management tools, so
there would always be a means to enable or disable the feature.  In
fact, that's specifically why I test that the Atomic Op completer bits
are unset in the root port before changing them so that this automatic
enablement could live alongside a command line option to statically
enable some bits.

That does however remind me that it is often good with these sorts of
"clever" automatic features to have an opt-out, so I'll likely add an
x-no-rp-atomics device option in the next version to provide that.
Thanks,

Alex



  reply	other threads:[~2023-05-31 22:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-26 23:15 [RFC PATCH v2 0/4] vfio/pci: Atomic Ops completer support Alex Williamson
2023-05-26 23:15 ` [RFC PATCH v2 1/4] linux-headers: Update for vfio capability reporting AtomicOps Alex Williamson
2023-05-30 13:19   ` Cédric Le Goater
2023-05-26 23:15 ` [RFC PATCH v2 2/4] vfio: Implement a common device info helper Alex Williamson
2023-05-31 10:18   ` Robin Voetter
2023-05-26 23:15 ` [RFC PATCH v2 3/4] pcie: Add a PCIe capability version helper Alex Williamson
2023-05-30 12:30   ` Cédric Le Goater
2023-05-31 22:02   ` Robin Voetter
2023-05-31 22:19     ` Philippe Mathieu-Daudé
2023-05-26 23:15 ` [RFC PATCH v2 4/4] vfio/pci: Enable AtomicOps completers on root ports Alex Williamson
2023-05-30 13:36   ` Cédric Le Goater
2023-05-31 22:03   ` Robin Voetter
2023-05-31 22:28   ` Philippe Mathieu-Daudé
2023-05-31 21:55 ` [RFC PATCH v2 0/4] vfio/pci: Atomic Ops completer support Robin Voetter
2023-05-31 22:24   ` Alex Williamson [this message]
2023-05-31 22:29     ` Philippe Mathieu-Daudé
2023-06-02 14:02       ` Philippe Mathieu-Daudé
2023-06-01  8:15     ` Robin Voetter
2023-05-31 22:31 ` Philippe Mathieu-Daudé

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=20230531162446.2bc9a26c.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=clg@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=robin@streamhpc.com \
    /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.