On 01/29/2013 03:23 AM, Daniel P. Berrange wrote: > On Mon, Jan 28, 2013 at 02:54:28PM -0700, Eric Blake wrote: >> On 01/26/2013 09:17 PM, Stefan Berger wrote: >>>> In a subsequent patch we now test inside that function whether the new >>>> command line parameter is available using the capability (from another >>>> patch) and create fd=/dev/set/10 and vhostfd=/dev/set/20 respectively >>>> *and* already add "-add-fd set=10,fd=21" and "-add-fd set=20,fd=23" to >>>> virCommand using the functions I already posted (as the lowest layer). >>>> >>>> Would it be that simple, or do we need to add more parameters to >>>> -add-fd set=10,fd=21,xyz under certain circumstances? >> >> Ideally, we'd also want to use the opaque parameter of each -add-fd >> call, so that when we later use QMP commands to query what fdsets exist, >> the opaque parameter can tell us what filenames we passed in (it makes >> bookkeeping easier if you know that fd 5 was tied to /dev/tpm, compared >> to just knowing that it is an open fd but not what it came from). > > That implies that you trust the output from QEMU monitor commands > to be telling you the truth. We can't do that, so IMHO we can't > rely on the 'opaque' parameter. Fair enough - libvirt will have to track in vm->priv anything that it needs for reconstructing state, even across libvirtd restarts. Still, we _ought_ to populate the opaque member with useful information, so that debugging is easier (that is, while libvirt can't rely on query-fdsets, a developer using 'virsh qemu-monitor-command' on a trusted guest certainly should be able to). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list