[libvirt] [PATCH] gconfig: Add GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_QEMU_XHCI
by Felipe Borges
Modern operating systems support qemu-xhci and that's available
since libvirt 3.3.x and qemu 2.9.x
Signed-off-by: Felipe Borges <feborges(a)redhat.com>
---
libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h b/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h
index d593764..3f93d7c 100644
--- a/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h
+++ b/libvirt-gconfig/libvirt-gconfig-domain-controller-usb.h
@@ -65,7 +65,8 @@ typedef enum {
GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_ICH9_UHCI2,
GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_ICH9_UHCI3,
GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_VT82C686B_UHCI,
- GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_PCI_OHCI
+ GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_PCI_OHCI,
+ GVIR_CONFIG_DOMAIN_CONTROLLER_USB_MODEL_QEMU_XHCI
} GVirConfigDomainControllerUsbModel;
GType gvir_config_domain_controller_usb_get_type(void);
--
2.24.1
4 years, 11 months
[libvirt] [PATCH 0/5] Get rid of "no_memory" labels
by Fabiano Fidêncio
As pointed out by Ján Tomko, "no_memory seems suspicious in the times of
abort()".
As libvirt decided to take the path to not report OOM and simply abort
when it happens, let's get rid of the no_memory labels and simplify the
code around them.
The two exceptions are:
- phyp code, as libvirt may end up dropping this code entirely;
- virfirewall.c code, as it seems we heavily really on firewall->err
being set to ENOMEM;
If one thinks that virfirewall.c should also be converted, please, shout
out and I'll work on that.
Fabiano Fidêncio (5):
conf: Get rid of "no_memory" labels
openvz: Get rid of "no_memory" labels
rpc: Get rid of "no_memory" labels
util: Get rid of "no_memory" labels
vbox: Get rid of "no_memory" labels
src/conf/capabilities.c | 16 ++--------
src/conf/domain_audit.c | 40 +++++++------------------
src/openvz/openvz_conf.c | 18 +++++------
src/rpc/virnetclient.c | 42 ++++++++------------------
src/util/virsysinfo.c | 64 +++++++++++++++-------------------------
src/util/virsysinfo.h | 2 ++
src/util/viruri.c | 28 +++++++-----------
src/vbox/vbox_common.c | 20 +++++--------
8 files changed, 75 insertions(+), 155 deletions(-)
--
2.24.1
4 years, 11 months
[libvirt] [PATCH] storage: Fix daemon crash on lookup storagepool by targetpath
by Yi Li
Causing a crash when storagePoolLookupByTargetPath because of
Some types of storage pool have no target elements.
Core was generated by `/usr/sbin/libvirtd'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt
0 0x0000ffff9e951388 in strcmp () from /lib64/libc.so.6
1 0x0000ffff92103e9c in storagePoolLookupByTargetPathCallback (
obj=0xffff7009aab0, opaque=0xffff801058b0) at storage/storage_driver.c:1649
2 0x0000ffff9f2c52a4 in virStoragePoolObjListSearchCb (
payload=0xffff801058b0, name=<optimized out>, opaque=<optimized out>)
at conf/virstorageobj.c:476
3 0x0000ffff9f1f2f7c in virHashSearch (ctable=0xffff800f4f60,
iter=iter@entry=0xffff9f2c5278 <virStoragePoolObjListSearchCb>,
data=data@entry=0xffff95af7488, name=name@entry=0x0) at util/virhash.c:696
4 0x0000ffff9f2c64f0 in virStoragePoolObjListSearch (pools=0xffff800f2ce0,
searcher=searcher@entry=0xffff92103e68 <storagePoolLookupByTargetPathCallback>,
opaque=<optimized out>) at conf/virstorageobj.c:505
5 0x0000ffff92101f54 in storagePoolLookupByTargetPath (conn=0xffff5c0009f0,
path=0xffff7009a850 "/vms/images") at storage/storage_driver.c:1672
Signed-off-by: Yi Li <yili(a)winhong.com>
---
src/storage/storage_driver.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
index a33328d..5863e1f 100644
--- a/src/storage/storage_driver.c
+++ b/src/storage/storage_driver.c
@@ -1713,6 +1713,12 @@ storagePoolLookupByTargetPathCallback(virStoragePoolObjPtr obj,
return false;
def = virStoragePoolObjGetDef(obj);
+
+ /* Some Storage pool types have no Target elements,
+ * so we should check it. */
+ if (def->target.path == NULL)
+ return false;
+
return STREQ(path, def->target.path);
}
--
2.7.5
4 years, 11 months
Re: [libvirt] Add support for vhost-user-scsi-pci/vhost-user-blk-pci
by Cole Robinson
FYI there's some more recent discussion over here:
https://www.redhat.com/archives/libvir-list/2019-December/msg00817.html
There isn't any objections to using <disk type='vhostuser'/> for
vhost-user-blk, so maybe that's a good place to start.
Thanks,
Cole
On 10/15/19 7:34 AM, Li Feng wrote:
> Cole Robinson <crobinso(a)redhat.com> 于2019年10月15日周二 上午1:48写道：
>>
>> On 10/14/19 3:12 AM, Li Feng wrote:
>>> Hi Cole & Michal,
>>>
>>> I'm sorry for my late response, I just end my journey today.
>>> Thank your response, your suggestion is very helpful to me.
>>>
>>> I have added Michal in this mail, Michal helps me review my initial patchset.
>>> (https://www.spinics.net/linux/fedora/libvir/msg191339.html)
>>>
>>
>> Whoops I missed that posting, I didn't realize you had sent patches!
>>
>>> All concern about this feature is the XML design.
>>> My original XML design exposes more details of Qemu.
>>>
>>> <vhost-user-blk-pci type='unix'>
>>> <source type='bind' path='/tmp/vhost-blk.sock'>
>>> <reconnect enabled='yes' timeout='5' />
>>> </source>
>>> <queue num='4'/>
>>> </vhost-user-blk-pci>
>>>
>>> As Cole's suggestion, the better design with all vhost-user-scsi/blk
>>> features would like this:
>>>
>>> vhost-user-blk:
>>>
>>> <disk type='vhostuser' device='disk'>
>>> <source type='unix' path='/path/to/vhost-user-blk.sock' mode='client'>
>>> <reconnect enabled='yes' timeout='5' />
>>> </source>
>>> <target dev='vda' bus='virtio'/>
>>> <queue num='4'/>
>>> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
>>> </disk>
>>>
>>> vhost-user-scsi:
>>>
>>> <disk type='vhostuser' device='disk'>
>>> <source type='unix' path='/path/to/vhost-user-scsi.sock' mode='client'>
>>> <reconnect enabled='yes' timeout='5' />
>>> </source>
>>> <target dev='sda' bus='scsi'/>
>>> <queue num='4'/>
>>> </disk>
>>>
>>
>> I think my SCSI idea is wrong, sorry. vhost-user-scsi is for passing a
>> scsi host adapter to the VM, correct? If so, then it's not really a
>> <disk>, and so using the existing vhost-scsi support in <hostdev> is
>> probably better. <hostdev> could possible be used for vhost-user-blk as well
>>
>> Can you provide some examples of full qemu command lines using
>> vhost-user-blk and vhost-user-scsi? Just linking to examples else where
>> is fine, but I'm wondering if there's more context
>
> You could check the vhost-user-scsi/blk examples from SPDK pages:
> https://spdk.io/doc/vhost.html
>
>>
>> Internally we already have an abstraction for vhost-scsi:
>>
>> <hostdev mode='subsystem' type='scsi_host'>
>> <source protocol='vhost' wwpn='XXX'/>
>> </hostdev>
>>
>>
>> The obvious extension would be
>>
>> <hostdev mode='subsystem' type='scsi_host'>
>> <source protocol='vhostuser' type='unix'
>> path='/path/to/vhost-user-scsi.sock' mode='client'/>
>> </hostdev>
>>
>> Internally implementing this will be weird. The <source> parameters are
>> only dictated by the hostdev type= field, but in this case they would be
>> dictated by the <source protocol=> field, and we would want to reuse the
>> internal chardev abstraction.
>>
>> vhost-user-blk could be implemented similarly, but with type='storage'
>> which is the way we pass through block devices to LXC guests, but it
>> isn't currently supported in the qemu driver.
>>
>> I dunno. Maybe Michal or danpb can provide guidance
>>
> @Michal, @danpb, could you give some guidance?
>>
>>> Conclusion:
>>> 1. Add new type(vhostuser) for disk label;
>>> 2. Add queue sub-label for disk to support multiqueue(<queue
>>> num='4'/>) or reusing the driver label
>>> (<driver name='vhostuser' queues='4'), which one is better?
>>> Qemu support multiqueue like this:
>>> -device vhost-user-scsi-pci,id=scsi0,chardev=spdk_vhost_scsi0,num_queues=4
>>> -device vhost-user-blk-pci,chardev=spdk_vhost_blk0,num-queues=4
>>>
>>
>> num-queues is already supported by libvirt for both <disk> and <hostdev>
>> with <driver queues=X/>, so whether we use <disk> or <hostdev> you won't
>> need to add any new XML here.
> Got it.
>
>>
>>> Another question:
>>> When qemu is connecting to a vhost-user-scsi controller[1], there may
>>> exist multiple LUNs under one target,
>>> then one disklabel(<disk/>) will represent multiple SCSI LUNs,
>>> the 'dev' property(<target dev='sda' bus='scsi'/>) will be ignored, right?
>>> In other words, for vhost-user-scsi disk, it more likes a controller,
>>> maybe the controller label is suitable.
>>>
>>
>> Yes you are right, and this was my understanding. But then its not
>> really a <controller> in libvirt's sense because we can't attach
>> emulated devices to it, so it's more a fit for the existing <hostdev>
>> vhost-user support. Unfortunately it's not really a clean fit anywhere,
>> there will have to be some kind of compromise. And I'm not sure if
>> <disk> or <hostdev> is right for vhost-user-blk, but hopefully others
>> have more clear opinions.
>
> I'm also confused about it.
> Thanks for your reply.
>
> Thanks,
> Feng Li
>
>>
>> Thanks,
>> Cole
>>
>>> I look forward to hearing from you as soon as possible.
>>>
>>> [1]: https://spdk.io/doc/vhost.html
>>>
>>> Feng Li
>>>
>>> Cole Robinson <crobinso(a)redhat.com> 于2019年10月10日周四 上午6:48写道：
>>>>
>>>> Sorry for the late reply, and thanks Jano for pointing out elsewhere
>>>> that this didn't receive a response.
>>>>
>>>> On 8/12/19 5:56 AM, Li Feng wrote:
>>>>> Hi Guys,
>>>>>
>>>>> And I want to add the vhost-user-scsi-pci/vhost-user-blk-pci support
>>>>> for libvirt.
>>>>>
>>>>> The usage in qemu like this:
>>>>>
>>>>> Vhost-SCSI
>>>>> -chardev socket,id=char0,path=/var/tmp/vhost.0
>>>>> -device vhost-user-scsi-pci,id=scsi0,chardev=char0
>>>>> Vhost-BLK
>>>>> -chardev socket,id=char1,path=/var/tmp/vhost.1
>>>>> -device vhost-user-blk-pci,id=blk0,chardev=char1
>>>>>
>>>>
>>>> Indeed that matches what I see for the qemu commits too:
>>>>
>>>> https://git.qemu.org/?p=qemu.git;a=commit;h=00343e4b54b
>>>> https://git.qemu.org/?p=qemu.git;a=commit;h=f12c1ebddf7
>>>>
>>>>> What type should I add for libvirt.
>>>>> Type1:
>>>>> <hostdev mode='subsystem' type='vhost-user'>
>>>>> <source protocol='vhost-user-scsi' path='/tmp/vhost-scsi.sock'></source>
>>>>> <alias name="vhost-user-scsi-disk1"/>
>>>>> </hostdev>
>>>>>
>>>>>
>>>>> Type2:
>>>>>
>>>>> <disk type='network' device='disk'>
>>>>> <driver name='qemu' type='raw' cache='none' io='native'/>
>>>>> <source protocol='vhost-user' path='/tmp/vhost-scsi.sock'>
>>>>> </source>
>>>>> <target dev='sdb' bus='vhost-user-scsi'/>
>>>>> <boot order='3'/>
>>>>> <alias name='scsi0-0-0-1'/>
>>>>> <address type='drive' controller='0' bus='0' target='0' unit='1'/>
>>>>> </disk>
>>>>>
>>>>>
>>>>> <disk type='network' device='disk'>
>>>>> <driver name='qemu' type='raw' cache='none' io='native'/>
>>>>> <source protocol='vhost-user' path='/tmp/vhost-blk.sock'>
>>>>> </source>
>>>>> <target dev='vda' bus='vhost-user-blk'/>
>>>>> <boot order='1'/>
>>>>> <alias name='virtio-disk0'/>
>>>>> <address type='pci' domain='0x0000' bus='0x00' slot='0x07'
>>>>> function='0x0'/>
>>>>> </disk>
>>>>>
>>>>
>>>> I think wiring this into <disk> makes more sense. <hostdev> is really an
>>>> abstraction for assigning a (typically) physical host device to the VM,
>>>> so it handles things like hiding a PCI device from the host, and passing
>>>> that exact device to the VM.
>>>>
>>>> In the vhost-user-scsi/blk case, the host device is just a special
>>>> process running on the other side of a socket, and the device
>>>> represented to the guest is a typical virtio device. So to me it makes
>>>> more sense as a <disk> with a <source> that points at that socket.
>>>>
>>>> target bus=virtio vs bus=scsi is already used to distinguish between
>>>> virtio-blk and virtio-scsi, so I think we can keep that bit as is, with
>>>> the <address type=drive|pci> to match. We just need to differentiate
>>>> between plain virtio and vhost-user
>>>>
>>>> network devices already have vhostuser support:
>>>>
>>>> <interface type='vhostuser'>
>>>> <source type='unix' path='/tmp/vhost1.sock' mode='server|client'/>
>>>> <model type='virtio'/>
>>>> </interface>
>>>>
>>>> Internally that <source> is a virDomainChrSourceDefPtr which is our
>>>> internal representation of a chardev. So I think something akin to this
>>>> is the way to go. It will likely require updating a LOT of places in the
>>>> code that check disk type= field, probably most places that care about
>>>> whether type=NETWORK or type=!NETWORK will need to be mirrored for the
>>>> new type.
>>>>
>>>> <disk type='vhostuser' device='disk'>
>>>> <source type='unix' path='/path/to/vhost-user-blk.sock' mode='client'/>
>>>> <target dev='vda' bus='virtio'/>
>>>> </disk>
>>>>
>>>> <disk type='vhostuser' device='disk'>
>>>> <source type='unix' path='/path/to/vhost-user-scsi.sock' mode='client'/>
>>>> <target dev='sda' bus='scsi'/>
>>>> </disk>
>>>>
>>>> - Cole
>>>
>>
>>
>> - Cole
>
- Cole
4 years, 11 months
[libvirt] libvirt API/design questions
by Cole Robinson
There's some pre-existing libvirt design questions I would like some
feedback on, and one new one
* `virsh blockresize` doesn't prevent shrink by default, couple users
have blown their foot off and there's attempts at patches.
https://www.redhat.com/archives/libvir-list/2019-October/msg00258.html
https://www.redhat.com/archives/libvir-list/2019-November/msg00843.html
Do we implement this as a protection in virsh, or change the API
behavior and require a new API flag to allow shrinking? Or some other idea?
* vhost-user-scsi and vhost-user-blk XML schema
https://www.redhat.com/archives/libvirt-users/2019-October/msg00018.html
Last proposal was using <hostdev> for this, which revisiting it now
makes more sense than <disk>, because it vhost-user-X doesn't seem to
use qemu's block layer at all. So vhost-user-scsi would be:
<hostdev mode='subsystem' type='scsi_host'>
<source protocol='vhostuser' type='unix'
path='/path/to/vhost-user-scsi.sock' mode='client'/>
</hostdev>
vhost-user-blk maybe requires a new type='block' ? Otherwise it's
unclear how to differentiate between the two. Regardless it would be
nice to give the original patch author guidance here, they seemed
motivated to get this working
* Splitting domain_conf up. There's 30k lines in domain_conf.c and 3500
in domain_conf.h, it would be nice to unwind it a bit. Getting some sign
off on this ahead of time is critical IMO so pieces can be posted and
committed quickly because they will obviously go out of date fast. My
thoughts:
- domain_def.[ch]: DomainDefXXX and enum definitions.
- probably New and Free functions too
- domain_parse.[ch]: XML parsing
- domain_format.[ch]: XML formatting
- domain_validate.[ch]: validate and postparse handling
- domain_util.[ch]: everything else, or keep it in domain_conf?
domain_def should be easy but no idea how intertwined the rest are. If
the domain_validate naming is acceptable for both validate and postparse
functions, we could use that naming for qemu_domain.c split too.
Also maybe it's worth considering if there's some way to sensibly split
the conf/ directory. We could add a top level domain/ directory, but
that's kinda ambiguously named as we already have network/ + storage/ +
secret/ etc that have different meanings. Maybe sub dirs like
conf/domain/ ? I'm curious if anyone has strong feelings either way.
There's not really a clear place to dump shared DomainDef code at the
moment, like possible domain_cgroup for sharing cgroup handling across
lxc + qemu
Thanks,
Cole
4 years, 11 months
[libvirt] virsh blockresize syntax is inconsistent with vol-resize and somewhat dangerous
by Tim Small
Hello,
virsh has two commands which can be used to resize block devices -
"blockresize" for volumes in use by and active guest, and "vol-resize"
for volumes which are not in use.
The vol-resize syntax allows to specify the size as a delta (increase or
decrease vs. the current size), and also refuses to shrink a volume
unless the "--shrink" argument is also passed.
Most other tools which can be used for block device resizing (outside of
libvirt) also have similar "--shrink" argument requirements when
reducing the size of an existing block device. e.g. ceph requires
"--allow-shrink" when using the "rbd resize" command.
The lack of such a safety device makes "blockresize" a foot-gun (which I
recently found to great effect when I typoed the domain name to another
valid domain).
It seems I am not alone in making this error e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902171
One possible solution would be to make a new command e.g. "domblkresize"
or perhaps "live-resize", which implement the "--shrink" and "--delta"
behaviour to make it consistent with "vol-resize" syntax, and mark the
"blockresize" command as deprecated in the documentation and help (so
that existing automation which depends on the current behaviour doesn't
break).
Any thoughts? Should I open this as an RFE?
Thanks,
Tim.
--
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309
4 years, 11 months
[libvirt] [PATCH v5 0/5] qemu_process: Glib sponsored cleanup
by Daniel Henrique Barboza
changes from previous version 4 [1]:
- patch 1:
* moved 'dev' inside the for loop in qemuProcessHandleBlockThreshold()
* moved 'id' inside the 'for' loop in qemuProcessLookupPTYs()
* moved 'path' inside both conditionals in qemuProcessBuildDestroyMemoryPaths()
* set 'template=NULL' in case g_mkdtemp() succeeds in qemuProcessQMPInit()
- patch 2: new patch. add g_autoptr() support for
qemuDomainLogContextPtr
- patch 3:
* using g_autoptr() on feasible virCommandPtr and
* qemuDomainLogContextPtr
[1] https://www.redhat.com/archives/libvir-list/2019-December/msg01311.html
Daniel Henrique Barboza (5):
qemu_process.c: use g_autofree
qemu_domain.h: add G_DEFINE_AUTOPTR_CLEANUP_FUNC for
qemuDomainLogContext
qemu_process.c: use g_autoptr()
qemu_process.c: remove cleanup labels after g_auto*() changes
qemu_process.c: remove 'cleanup' label from
qemuProcessCreatePretendCmd()
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_process.c | 445 +++++++++++++++-------------------------
2 files changed, 166 insertions(+), 280 deletions(-)
--
2.24.1
4 years, 11 months
[libvirt] [PATCH v4 0/4] qemu_process: Glib sponsored cleanup
by Daniel Henrique Barboza
This series got buried a few months ago. Let's go onward unto
the 20s with no one left behind.
changes from version 3 [1]:
- rebased to master at commit 330b556829
- removed former patch 4. The 'g_strdup_printf' change was
made along the road
- new patch 4: I am sending this one in separate to patch 3
because this unneeded label was already in the code, being
unrelated to the changes of this series. The maintainer is
welcome to squash it into patch 3.
[1] https://www.redhat.com/archives/libvir-list/2019-October/msg01080.html
Daniel Henrique Barboza (4):
qemu_process.c: use g_autofree
qemu_process.c: use g_autoptr()
qemu_process.c: remove cleanup labels after g_auto*() changes
qemu_process.c: remove 'cleanup' label from
qemuProcessCreatePretendCmd()
src/qemu/qemu_process.c | 429 +++++++++++++++-------------------------
1 file changed, 157 insertions(+), 272 deletions(-)
--
2.23.0
4 years, 11 months
[libvirt] [PATCH] schemas: Allow additional qemu cmd line arguments/env variables and qemuCaps to be interleaved
by Michal Privoznik
While command line arguments are sort of positional (becasue you
have to have two entries, one for "-arg" the other for "value"),
it doesn't really matter whether env variables come before or
after command line arguments.
And it matter even less when playing with qemu capabilities.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/schemas/domaincommon.rng | 54 +++++++++++++++++++----------------
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 5f1d4a34a4..b87457382a 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -6295,37 +6295,41 @@
-->
<define name="qemucmdline">
<element name="commandline" ns="http://libvirt.org/schemas/domain/qemu/1.0">
- <zeroOrMore>
- <element name="arg">
- <attribute name='value'/>
- </element>
- </zeroOrMore>
- <zeroOrMore>
- <element name="env">
- <attribute name='name'>
- <ref name="filter-param-name"/>
- </attribute>
- <optional>
+ <interleave>
+ <zeroOrMore>
+ <element name="arg">
<attribute name='value'/>
- </optional>
- <empty/>
- </element>
- </zeroOrMore>
+ </element>
+ </zeroOrMore>
+ <zeroOrMore>
+ <element name="env">
+ <attribute name='name'>
+ <ref name="filter-param-name"/>
+ </attribute>
+ <optional>
+ <attribute name='value'/>
+ </optional>
+ <empty/>
+ </element>
+ </zeroOrMore>
+ </interleave>
</element>
</define>
<define name="qemucapabilities">
<element name="capabilities" ns="http://libvirt.org/schemas/domain/qemu/1.0">
- <zeroOrMore>
- <element name="add">
- <attribute name="capability"/>
- </element>
- </zeroOrMore>
- <zeroOrMore>
- <element name="del">
- <attribute name="capability"/>
- </element>
- </zeroOrMore>
+ <interleave>
+ <zeroOrMore>
+ <element name="add">
+ <attribute name="capability"/>
+ </element>
+ </zeroOrMore>
+ <zeroOrMore>
+ <element name="del">
+ <attribute name="capability"/>
+ </element>
+ </zeroOrMore>
+ </interleave>
</element>
</define>
--
2.24.1
4 years, 11 months
[libvirt] [PATCH] util: add note about event file descriptors on Windows
by Daniel P. Berrangé
When using GNULIB with Winsock, libvirt will never see the normal HANDLE
objects, instead GNULIB guarantees that libvirt gets a C runtime file
descriptor. The GNULIB poll impl also expects to get C runtime file
descriptors rather than HANDLE objects. Document this behaviour so that
it is clear to applications providing event loop implementations if they
need Windows portability.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
include/libvirt/libvirt-event.h | 4 ++++
src/util/virevent.c | 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/include/libvirt/libvirt-event.h b/include/libvirt/libvirt-event.h
index 734dbdcbc1..facdc3a3ec 100644
--- a/include/libvirt/libvirt-event.h
+++ b/include/libvirt/libvirt-event.h
@@ -67,6 +67,10 @@ typedef void (*virEventHandleCallback)(int watch, int fd, int events, void *opaq
* listen for specific events. The same file handle can be registered
* multiple times provided the requested event sets are non-overlapping
*
+ * @fd will always be a C runtime file descriptor. On Windows
+ * the _get_osfhandle() method can be used if a HANDLE is required
+ * instead.
+ *
* If the opaque user data requires free'ing when the handle
* is unregistered, then a 2nd callback can be supplied for
* this purpose. This callback needs to be invoked from a clean stack.
diff --git a/src/util/virevent.c b/src/util/virevent.c
index f6c797724e..fd5d8f5bf1 100644
--- a/src/util/virevent.c
+++ b/src/util/virevent.c
@@ -60,6 +60,13 @@ static virEventRemoveTimeoutFunc removeTimeoutImpl;
* requires that an event loop has previously been registered with
* virEventRegisterImpl() or virEventRegisterDefaultImpl().
*
+ * @fd must always always be a C runtime file descriptor. On Windows
+ * if the caller only has a HANDLE, the _open_osfhandle() method can
+ * be used to open an associated C runtime file descriptor for use
+ * with this API. After opening a runtime file descriptor, CloseHandle()
+ * must not be used, instead close() will close the runtime file
+ * descriptor and its original associated HANDLE.
+ *
* Returns -1 if the file handle cannot be registered, otherwise a handle
* watch number to be used for updating and unregistering for events.
*/
--
2.21.0
4 years, 11 months