[Qemu-devel] [PATCH v3 0/4] command line fd passing using fd sets

[Qemu-devel] [PATCH v3 0/4] command line fd passing using fd sets

[Corey Bryant]

This series adds command line file descriptor passing support
via a new -add-fd option.  This is a follow-on to the existing
QMP fd passing support provided in the following patch series:
comments.gmane.org/gmane.comp.emulators.qemu/165463

The new -add-fd option is designed to mirror the add-fd QMP
option as much as possible.

Corey Bryant (4):
  monitor: Allow add-fd to any specified fd set
  monitor: Enable adding an inherited fd to an fd set
  monitor: Prevent removing fd from set during init
  qemu-config: Add new -add-fd command line option

 monitor.c        | 142 +++++++++++++++++++++++++++++++++----------------------
 monitor.h        |   3 ++
 qapi-schema.json |   2 +-
 qemu-config.c    |  22 +++++++++
 qemu-options.hx  |  36 ++++++++++++++
 vl.c             |  72 ++++++++++++++++++++++++++++
 6 files changed, 220 insertions(+), 57 deletions(-)

-- 
1.7.11.4

Re: [Qemu-devel] [PATCH v3 0/4] command line fd passing using fd sets

[Eric Blake]

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

On 10/16/2012 11:51 AM, Corey Bryant wrote:
> This series adds command line file descriptor passing support
> via a new -add-fd option.  This is a follow-on to the existing
> QMP fd passing support provided in the following patch series:
> comments.gmane.org/gmane.comp.emulators.qemu/165463
> 
> The new -add-fd option is designed to mirror the add-fd QMP
> option as much as possible.

Before this can still be useful in libvirt, we need a way to pass in fds
for all of a backing chain, and not just the top-level.  And you can't
argue that libvirt should be temporarily rewriting qcow2 metadata to
stick in names such as /dev/fdset/1 into the metadata.  Consider the
case of:

                        /- guest1.img
base.img <- snap1.img <
                        \- guest2.img

snap1.img is supposed to be read-only, and there's no guarantee that
/dev/fdset/1 will be available for both guest1 and guest2 to rewrite the
header.  Thus, I argue that snap1.img must encode the name base.img in
its metadata, but that we must also have a way to tell qemu to open
/dev/fdset/1 instead of trying open(base.img) in order to get the open
fd for base.img.

But even though we are still not at a point where the overall feature is
useful, I can at least review these patches for getting us incrementally
closer to our goal.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 617 bytes --]

Re: [Qemu-devel] [PATCH v3 0/4] command line fd passing using fd sets

[Corey Bryant]

On 10/16/2012 03:26 PM, Eric Blake wrote:
> On 10/16/2012 11:51 AM, Corey Bryant wrote:
>> This series adds command line file descriptor passing support
>> via a new -add-fd option.  This is a follow-on to the existing
>> QMP fd passing support provided in the following patch series:
>> comments.gmane.org/gmane.comp.emulators.qemu/165463
>>
>> The new -add-fd option is designed to mirror the add-fd QMP
>> option as much as possible.
>
> Before this can still be useful in libvirt, we need a way to pass in fds
> for all of a backing chain, and not just the top-level.  And you can't
> argue that libvirt should be temporarily rewriting qcow2 metadata to
> stick in names such as /dev/fdset/1 into the metadata.  Consider the
> case of:
>
>                          /- guest1.img
> base.img <- snap1.img <
>                          \- guest2.img
>
> snap1.img is supposed to be read-only, and there's no guarantee that
> /dev/fdset/1 will be available for both guest1 and guest2 to rewrite the
> header.  Thus, I argue that snap1.img must encode the name base.img in
> its metadata, but that we must also have a way to tell qemu to open
> /dev/fdset/1 instead of trying open(base.img) in order to get the open
> fd for base.img.

I think the -blockdev command is going to solve this.

Stefan, do you have any information on the -blockdev support?

>
> But even though we are still not at a point where the overall feature is
> useful, I can at least review these patches for getting us incrementally
> closer to our goal.
>

Thanks Eric.


-- 
Regards,
Corey Bryant