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
