Re: [PATCH v3 03/12] vfio-user: define vfio-user-server object

[Stefan Hajnoczi]

On Fri, Oct 29, 2021 at 02:42:49PM +0000, Jag Raman wrote:
> > On Oct 27, 2021, at 11:40 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > On Mon, Oct 11, 2021 at 01:31:08AM -0400, Jagannathan Raman wrote:
> >> diff --git a/hw/remote/vfio-user-obj.c b/hw/remote/vfio-user-obj.c
> >> new file mode 100644
> >> index 0000000000..c2a300f0ff
> >> --- /dev/null
> >> +++ b/hw/remote/vfio-user-obj.c
> >> @@ -0,0 +1,173 @@
> >> +/**
> >> + * QEMU vfio-user-server server object
> >> + *
> >> + * Copyright © 2021 Oracle and/or its affiliates.
> >> + *
> >> + * This work is licensed under the terms of the GNU GPL-v2, version 2 or 
> >> later.
> >> + *
> >> + * See the COPYING file in the top-level directory.
> >> + *
> >> + */
> >> +
> >> +/**
> >> + * Usage: add options:
> >> + *     -machine x-remote
> >> + *     -device <PCI-device>,id=<pci-dev-id>
> >> + *     -object vfio-user-server,id=<id>,type=unix,path=<socket-path>,
> > 
> > I expected socket.type= and socket.path= based on the QAPI schema. Is
> > this command-line example correct?
> 
> When I tried the “socket.path” approach, QEMU was not able to parse the
> arguments. So I had to break it down to a series of individual members.
> 
> If “socket.path” is the expected way, I’ll see why the parser is not working
> as expected. 

CCing Markus regarding QAPI.

I'm surprised because the QAPI schema for vfio-user-server objects is:

  { 'struct': 'VfioUserServerProperties',
    'data': { 'socket': 'SocketAddress', 'device': 'str' } }

It's not clear to me why the command-line parser flattens the 'socket'
field into its 'type' and 'path' sub-fields in your example:

  -object 
vfio-user-server,id=<id>,type=unix,path=<socket-path>,device=<pci-dev-id>

Maybe because SocketAddress is an enum instead of a struct?

Imagine a second SocketAddress field is added to vfio-user-server. How
can the parser know which field 'type' and 'path' belong to? I tried it:

  { 'struct': 'VfioUserServerProperties',
    'data': { 'socket': 'SocketAddress', 'socket2': 'SocketAddress', 'device': 
'str' } }

Now the parser refuses any input I've tried. For example:

  $ build/qemu-system-x86_64 -object 
vfio-user-server,id=s,device=asdf,type=unix,path=asdf,type=unix
  qemu-system-x86_64: -object 
vfio-user-server,id=s,device=asdf,type=unix,path=asdf,type=unix: Parameter 
'type' is missing

A similar case happens if the parent struct has 'type' or 'path' fields.
They collide with the SocketAddress union fields. I didn't test this
though.

Questions for Markus:
1. Do you know why the parser behaves like this?
2. Is it good practice to embed SocketAddress into parent structs or
   should we force it into a struct?

Stefan

signature.asc
Description: PGP signature