Re: [PATCH v5 50/50] multi-process: add configure and usage information

[Stefan Hajnoczi <stefanha@redhat.com>]

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

On Fri, Feb 28, 2020 at 10:43:44AM -0800, Elena Ufimtseva wrote:
> On Thu, Feb 27, 2020 at 04:58:04PM +0000, Stefan Hajnoczi wrote:
> > On Mon, Feb 24, 2020 at 03:55:41PM -0500, Jagannathan Raman wrote:
> > > +* The devices to be emulated in the separate process are defined as
> > > +  before with addition of "rid" suboption that serves as a remote group
> > > +  identificator.
> > > +
> > > +  -device <device options>,rid="remote process id"
> > > +
> > > +  For example, for non multi-process qemu:
> > > +    -device lsi53c895a,id=scsi0 device
> > > +    -device scsi-hd,drive=drive0,bus=scsi0.0,scsi-id=0
> > > +    -drive id=drive0,file=data-disk.img
> > > +
> > > +  and for multi-process qemu and no libvirt
> > > +  support (i.e. QEMU forks child processes):
> > > +    -device lsi53c895a,id=scsi0,rid=0
> > > +    -device scsi-hd,drive=drive0,bus=scsi0.0,scsi-id=0,rid=0
> > 
> > This approach is invasive:
> >  * lsi53c895a should not need to be modified with a new rid= option.
> >  * QEMU should not know about the scsi-hd device or drive0.  Only the
> >    device emulation process needs to know about scsi-hd.
> > 
> > In order to cleanly separate QEMU and the device emulation process
> > syntax like this is needed:
> > 
> >   -object remote-device,id=rid0,...
> >   -device remote-pci-device,id=scsi0,remote-device=rid0
> > 
> > The "remote-device" object could be part of remote-pci-device, but
> > keeping it separate may be useful in the future in order to support
> > things like reconnection.
> > 
> > The generic "remote-pci-device" device handles any remote PCI device,
> > not just the LSI SCSI controller.
> > 
> > Do you agree with this approach?
> > 
> 
> We discussed these changes and they seem to be along the lines with
> the future work on vfio over socket approach we will be working on later.
> 
> Could we for this experimental version have the changes you propose here
> with one modification - instead of having generic remote-pci-device imply that that is LSI
> device? And while we work towards vfio over socket this will become any remote
> PCI device?

Yes, that sounds good.

> > > +  The drives to be emulated by the remote process are specified as part of
> > > +  this command sub-option. The device to be used to connect to the monitor
> > > +  is also specified as part of this suboption.
> > > +
> > > +  For example, the following option adds a drive and monitor to the remote
> > > +  process:
> > > +  -remote rid=0,exec="qemu-scsi-dev",command="-drive id=drive0,,file=data-disk.img -monitor unix:/home/qmp-sock,,server,,nowait"
> > > +
> > > +  Note: There's an issue with this "command" sub-option which we are in the
> > > +  process of fixing. To work around this issue, it requires additional
> > > +  "comma" characters as illustrated above, and in the example below.
> > 
> > command= (which could be called args= for clarity) will be difficult to
> > use not just because of comma escaping but also because of double-quote
> > escaping.  How do you pass a command-line argument that contains spaces?
> 
> Yes, this is not great. And spaces are the problem at the moment.
> I am looking if the -object has some properties that can allow for arbitrary
> strings. Maybe such as data for "secret" object  would do?

I'm not aware of a way to avoid the comma escaping.  The space escaping
is a question of how the remote process is spawned.  If the command-line
is processed by a shell like with system(3) then backslash can be used
to escape spaces.

Stefan

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