[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 50/50] multi-process: add configure and usage information
From: |
Stefan Hajnoczi |
Subject: |
Re: [PATCH v5 50/50] multi-process: add configure and usage information |
Date: |
Fri, 6 Mar 2020 16:42:48 +0000 |
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
signature.asc
Description: PGP signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH v5 50/50] multi-process: add configure and usage information,
Stefan Hajnoczi <=