From: Stefan Hajnoczi <stefanha@redhat.com>
To: John Johnson <john.g.johnson@oracle.com>
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
Jag Raman <jag.raman@oracle.com>,
"swapnil.ingle@nutanix.com" <swapnil.ingle@nutanix.com>,
John Levon <john.levon@nutanix.com>,
QEMU Devel Mailing List <qemu-devel@nongnu.org>,
Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH RFC 04/19] vfio-user: Define type vfio_user_pci_dev_info
Date: Thu, 29 Jul 2021 09:22:00 +0100 [thread overview]
Message-ID: <YQJlKG/RWZa3x+21@stefanha-x1.localdomain> (raw)
In-Reply-To: <239B3640-8D08-4380-9812-E55501EE2F5D@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 4117 bytes --]
On Thu, Jul 29, 2021 at 12:55:08AM +0000, John Johnson wrote:
>
>
> > On Jul 28, 2021, at 3:16 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> > On Sun, Jul 18, 2021 at 11:27:43PM -0700, Elena Ufimtseva wrote:
> >> From: John G Johnson <john.g.johnson@oracle.com>
> >>
> >> New class for vfio-user with its class and instance
> >> constructors and destructors.
> >>
> >> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> >> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> >> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> >> ---
> >> hw/vfio/pci.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 49 insertions(+)
> >>
> >> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> >> index bea95efc33..554b562769 100644
> >> --- a/hw/vfio/pci.c
> >> +++ b/hw/vfio/pci.c
> >> @@ -42,6 +42,7 @@
> >> #include "qapi/error.h"
> >> #include "migration/blocker.h"
> >> #include "migration/qemu-file.h"
> >> +#include "hw/vfio/user.h"
> >>
> >> #define TYPE_VFIO_PCI_NOHOTPLUG "vfio-pci-nohotplug"
> >>
> >> @@ -3326,3 +3327,51 @@ static void register_vfio_pci_dev_type(void)
> >> }
> >>
> >> type_init(register_vfio_pci_dev_type)
> >> +
> >> +static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
> >> +{
> >> + ERRP_GUARD();
> >> + VFIOUserPCIDevice *udev = VFIO_USER_PCI(pdev);
> >> +
> >> + if (!udev->sock_name) {
> >> + error_setg(errp, "No socket specified");
> >> + error_append_hint(errp, "Use -device vfio-user-pci,socket=<name>\n");
> >> + return;
> >> + }
> >> +}
> >> +
> >> +static void vfio_user_instance_finalize(Object *obj)
> >> +{
> >> +}
> >> +
> >> +static Property vfio_user_pci_dev_properties[] = {
> >> + DEFINE_PROP_STRING("socket", VFIOUserPCIDevice, sock_name),
> >
> > Please use SocketAddress so that alternative socket connection details
> > can be supported without inventing custom syntax for vfio-user-pci. For
> > example, file descriptor passing should be possible.
> >
> > I think this requires a bit of command-line parsing work, so don't worry
> > about it for now, but please add a TODO comment. When the -device
> > vfio-user-pci syntax is finalized (i.e. when the code is merged and the
> > device name doesn't start with the experimental x- prefix), then it
> > needs to be solved.
> >
>
> What do you want the options to look like at the endgame? I’d
> rather work backward from that than have several different flavors of
> options as new socket options are added. I did look at -chardev socket,
> and it was confusing enough that I went for the simple string.
The standard socket syntax is present in qemu-storage-daemon's --export
and --nbd-server options:
addr.type=inet,addr.host=<host>,addr.port=<port>
addr.type=unix,addr.path=<socket-path>
addr.type=fd,addr.str=<fd>
--export and --nbd-server use QAPI to generate parsers for these options
(they use 'SocketAddress' from qapi/sockets.json). I'm not sure whether
it's easier to reuse the QAPI parser or to simply add qdev properties
mimicking the same syntax. Either way, there should probably be a common
qdev property API for SocketAddress values.
> >> + DEFINE_PROP_BOOL("secure-dma", VFIOUserPCIDevice, secure, false),
> >
> > I'm not sure what "secure-dma" means and the "secure" variable name is
> > even more inscrutable. Does this mean don't share memory so that each
> > DMA access is checked individually?
> >
>
> Yes. Do you have another name you’d prefer? “no-shared-mem”?
I'm not sure other property names are much clearer, so feel free to
stick with "secure-dma". Renaming the "secure" field to "secure_dma" and
adding a comment that clarifies its purpose would be enough.
Here are some options:
- The vfio-user protocol message for sharing memory is called
VFIO_USER_DMA_MAP. The option could be dma-map=on|off (default on).
But this is based on protocol internals and may not be clear to users.
- shared-mem=on|off
- shared-ram=on|off
Thanks,
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-07-29 8:23 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-19 6:27 [PATCH RFC 00/19] vfio-user implementation Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 01/19] vfio-user: introduce vfio-user protocol specification Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 02/19] vfio-user: add VFIO base abstract class Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 03/19] vfio-user: define VFIO Proxy and communication functions Elena Ufimtseva
2021-07-27 16:34 ` Stefan Hajnoczi
2021-07-28 18:08 ` John Johnson
2021-07-29 8:06 ` Stefan Hajnoczi
2021-07-19 6:27 ` [PATCH RFC 04/19] vfio-user: Define type vfio_user_pci_dev_info Elena Ufimtseva
2021-07-28 10:16 ` Stefan Hajnoczi
2021-07-29 0:55 ` John Johnson
2021-07-29 8:22 ` Stefan Hajnoczi [this message]
2021-07-19 6:27 ` [PATCH RFC 05/19] vfio-user: connect vfio proxy to remote server Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 06/19] vfio-user: negotiate protocol with " Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 07/19] vfio-user: define vfio-user pci ops Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 08/19] vfio-user: VFIO container setup & teardown Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 09/19] vfio-user: get device info and get irq info Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 10/19] vfio-user: device region read/write Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 11/19] vfio-user: get region and DMA map/unmap operations Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 12/19] vfio-user: probe remote device's BARs Elena Ufimtseva
2021-07-19 22:59 ` Alex Williamson
2021-07-20 1:39 ` John Johnson
2021-07-20 3:01 ` Alex Williamson
2021-07-19 6:27 ` [PATCH RFC 13/19] vfio-user: respond to remote DMA read/write requests Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 14/19] vfio_user: setup MSI/X interrupts and PCI config operations Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 15/19] vfio-user: vfio user device realize Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 16/19] vfio-user: pci reset Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 17/19] vfio-user: probe remote device ROM BAR Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 18/19] vfio-user: migration support Elena Ufimtseva
2021-07-19 6:27 ` [PATCH RFC 19/19] vfio-user: add migration cli options and version negotiation Elena Ufimtseva
2021-07-19 20:00 ` [PATCH RFC server 00/11] vfio-user server in QEMU Jagannathan Raman
2021-07-19 20:00 ` [PATCH RFC server 01/11] vfio-user: build library Jagannathan Raman
2021-07-19 20:24 ` John Levon
2021-07-20 12:06 ` Jag Raman
2021-07-20 12:20 ` Marc-André Lureau
2021-07-20 13:09 ` John Levon
2021-07-19 20:00 ` [PATCH RFC server 02/11] vfio-user: define vfio-user object Jagannathan Raman
2021-07-19 20:00 ` [PATCH RFC server 03/11] vfio-user: instantiate vfio-user context Jagannathan Raman
2021-07-19 20:00 ` [PATCH RFC server 04/11] vfio-user: find and init PCI device Jagannathan Raman
2021-07-26 15:05 ` John Levon
2021-07-28 17:08 ` Jag Raman
2021-07-19 20:00 ` [PATCH RFC server 05/11] vfio-user: run vfio-user context Jagannathan Raman
2021-07-20 14:17 ` Thanos Makatos
2021-08-13 14:51 ` Jag Raman
2021-08-16 12:52 ` John Levon
2021-08-16 14:10 ` Jag Raman
2021-07-19 20:00 ` [PATCH RFC server 06/11] vfio-user: handle PCI config space accesses Jagannathan Raman
2021-07-26 15:10 ` John Levon
2021-07-19 20:00 ` [PATCH RFC server 07/11] vfio-user: handle DMA mappings Jagannathan Raman
2021-07-20 14:38 ` Thanos Makatos
2021-07-19 20:00 ` [PATCH RFC server 08/11] vfio-user: handle PCI BAR accesses Jagannathan Raman
2021-07-19 20:00 ` [PATCH RFC server 09/11] vfio-user: handle device interrupts Jagannathan Raman
2021-07-19 20:00 ` [PATCH RFC server 10/11] vfio-user: register handlers to facilitate migration Jagannathan Raman
2021-07-20 14:05 ` Thanos Makatos
2021-07-19 20:00 ` [PATCH RFC server 11/11] vfio-user: acceptance test Jagannathan Raman
2021-07-20 16:12 ` Thanos Makatos
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=YQJlKG/RWZa3x+21@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=elena.ufimtseva@oracle.com \
--cc=jag.raman@oracle.com \
--cc=john.g.johnson@oracle.com \
--cc=john.levon@nutanix.com \
--cc=qemu-devel@nongnu.org \
--cc=swapnil.ingle@nutanix.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 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).