Re: [libvirt] [PATCH 02/20] libxl: Fix possible deadlock in libxlDomainMigrateBegin3Params

On 03/09/2018 09:47 AM, John Ferlan wrote: Commit id '45697fe5' added a check for "Domain-0" to generate an error during libxlDomainMigrateBegin3Params; however, by returning NULL, the @vm was left locked since libxlDomObjFromDomain returns a locked @vm. Signed-off-by: John Ferlan

[libvirt] libvirt-snmp status

Hi All, I'd like to enquire about the status of libvirt-snmp. It hasn't had any commits for a couple of years and no longer compiles against recent versions of net-snmp. As I understand it, upstream net-snmp deprecated and then removed the C type "U64" as it conflicts with Perl. Fortunately this

Re: [libvirt] [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

On Thu, Mar 08, 2018 at 09:47:27PM +0100, Laszlo Ersek wrote: > On 03/08/18 16:47, Daniel P. Berrangé wrote: > > On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote: [...] > >> For OVMF (x86), I guess the initial set of properties should come from > >> the "-D FOO[=BAR]" build flags

Re: [libvirt] [PATCH v2 06/12] qemu: Generate cmd line at startup

On 03/08/2018 01:18 AM, John Ferlan wrote: > > > On 03/06/2018 12:31 PM, Michal Privoznik wrote: >> On 03/02/2018 02:22 PM, John Ferlan wrote: >>> >>> >>> On 02/21/2018 01:11 PM, Michal Privoznik wrote: >>> What happens when there's more than one disk using the managed mode >>> where you have

[libvirt] [PATCH 1/3] virDomainDeviceValidateAliasForHotplug: Use correct domain defintion

https://bugzilla.redhat.com/show_bug.cgi?id=1553075 For some weird reason this function is getting live and persistent def for domain but then accesses vm->def and vm->newDef directly. This is rather unsafe as we can be accessing NULL pointer. Signed-off-by: Michal Privoznik

[libvirt] [PATCH 3/3] qemu: Forbid user aliases for USB controllers

https://bugzilla.redhat.com/show_bug.cgi?id=1552127 These are bit different than other devices. Their alias also specify the name of the bus. For instance, if there are these 'joined' USB devices: which translates to cmd line as: -device

[libvirt] [PATCH 0/3] Couple of user alias fixes

The deeper into the rabbit hole we go the more I think it was a mistake to let users specify device aliases. Michal Privoznik (3): virDomainDeviceValidateAliasForHotplug: Use correct domain defintion conf: Check for user aliases duplicates only qemu: Forbid user aliases for USB controllers

[libvirt] [PATCH 2/3] conf: Check for user aliases duplicates only

https://bugzilla.redhat.com/show_bug.cgi?id=1553162 When validating a device XML config we check if user provided alias is unique. We do this by maintaining a hash table of device aliases as we iterated over all devices defined for the domain. However, it may happen that what appears as two

Re: [libvirt] [RFC] Defining firmware (OVMF, et al) metadata format & file

On Thu, Mar 08, 2018 at 08:52:45AM +0100, Gerd Hoffmann wrote: > Hi, > > > > [*] Open question: Who, between QEMU and libvirt, should define the said > > > firmware metadata format and file? > > > > IMHO QEMU should be defining the format, because the file will contain > > info about certain

[libvirt] [PATCH 03/20] libxl: Properly cleanup after libxlDomObjFromDomain

Commit id '9ac945078' altered libxlDomObjFromDomain to return a locked *and* ref counted object for some specific purposes; however, it neglected to alter all the consumers of the helper to use virDomainObjEndAPI thus leaving many objects with extra ref counts. The two consumers for

[libvirt] [PATCH 04/20] libxl: Use virDomainObjListFindBy{UUID|ID}Ref

For libxlDomainLookupByID and libxlDomainLookupByUUID let's return a locked and referenced @vm object so that callers can then use the common and more consistent virDomainObjEndAPI in order to handle cleanup rather than needing to know that the returned object is locked and calling

[libvirt] [PATCH 09/20] uml: Create accessors to virDomainObjListFindByUUID

Rather than repeat code throughout, create and use a couple of accessors in order to lookup by UUID. This will also generate a common error message including the failed uuidstr for lookup rather than just returning nothing in some instances. Signed-off-by: John Ferlan ---

[libvirt] [PATCH 06/20] openvz: Create accessors to virDomainObjListFindByUUID

Rather than repeat code throughout, create and use a couple of accessors in order to lookup by UUID. Signed-off-by: John Ferlan --- src/openvz/openvz_driver.c | 266 + 1 file changed, 76 insertions(+), 190 deletions(-) diff --git

[libvirt] [PATCH 13/20] vmware: Add more descriptive error message on Find failure

If vmwareDomainLookupByID or vmwareDomainLookupByName fails to find a vm, let's be a bit more descriptive by providing the failing id or name in the error message. Signed-off-by: John Ferlan --- src/vmware/vmware_driver.c | 6 -- 1 file changed, 4 insertions(+), 2

[libvirt] [PATCH 05/20] openvz: Cleanup indention

Some of the indents were only 2 spaces, make consistent w/ 4 spaces Signed-off-by: John Ferlan --- src/openvz/openvz_driver.c | 64 +++--- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/src/openvz/openvz_driver.c

[libvirt] [PATCH 11/20] uml: Use virDomainObjListFindBy{UUID|ID}Ref

For umlDomObjFromDomainLocked and umlDomainLookupByID let's return a locked and referenced @vm object so that callers can then use the common and more consistent virDomainObjEndAPI in order to handle cleanup rather than needing to know that the returned object is locked and calling

[libvirt] [PATCH 12/20] vmware: Create accessors to virDomainObjListFindByUUID

Rather than repeat code throughout, create and use a couple of accessors in order to lookup by UUID. Signed-off-by: John Ferlan --- src/vmware/vmware_driver.c | 180 +++-- 1 file changed, 61 insertions(+), 119 deletions(-) diff --git

[libvirt] [PATCH 20/20] conf: Rework/rename virDomainObjListFindByIDRef

Rework the code such that virDomainObjListFindByID will always return a locked/ref counted object so that the callers can always do the same cleanup logic to call virDomainObjEndAPI. Makes accessing the objects much more consistent. NB: There were 3 callers (lxcDomainLookupByID,

[libvirt] [PATCH 00/20] Rework/rename virDomainObjListFindBy{UUID|ID}Ref

First, don't be scared off by 20 patches... They're not that difficult. Second, don't be scared off by the all the various code touched. Third, look at all the lines of code being removed! That's unlike my normal patch series! This is really the end game of what I started last year trying to

[libvirt] [PATCH 15/20] vmware: Use virDomainObjListFindBy{UUID|ID}Ref

For vmwareDomObjFromDomainLocked and vmwareDomainLookupByID let's return a locked and referenced @vm object so that callers can then use the common and more consistent virDomainObjEndAPI in order to handle cleanup rather than needing to know that the returned object is locked and calling

[libvirt] [PATCH 17/20] vz: Use virDomainObjListFindBy{UUID|ID}Ref

For vzDomainLookupByID and vzDomainLookupByUUID let's return a locked and referenced @vm object so that callers can then use the common and more consistent virDomainObjEndAPI in order to handle cleanup rather than needing to know that the returned object is locked and calling virObjectUnlock. The

[libvirt] [PATCH 18/20] test: Use virDomainObjListFindByUUIDRef

Rather than using virDomainObjListFindByUUID, use the ref counting API in order to use virDomainObjEndAPI instead of virObjectUnlock (for common look and feel). Signed-off-by: John Ferlan --- src/test/test_driver.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)

[libvirt] [PATCH 14/20] vmware: Properly clean up in vmwareDomainLookupByName

The virDomainObjListFindByName returns a locked and reffed domain object, all we did was unlock it, leaving an extra ref. Use the virDomainObjEndAPI to cleanup instead. Signed-off-by: John Ferlan --- src/vmware/vmware_driver.c | 3 +-- 1 file changed, 1 insertion(+), 2

[libvirt] [PATCH 16/20] vz: Unify vzDomObjFromDomain{Ref}

Rather than have two API's doing different things for different callers, let's make one API that will always return a locked and ref counted object. That way, the callers will always know that they must call virDomainObjEndAPI and not have to decide whether they should call virObjectUnlock

[libvirt] [PATCH 19/20] conf: Rework/rename virDomainObjListFindByUUIDRef

Now that every caller is using virDomainObjListFindByUUIDRef, let's just remove it and keep the name as virDomainObjListFindByUUID. That allows reworking the virdomainobjlist API's a bit to be more like virDomainObjListFindByName. Signed-off-by: John Ferlan ---

[libvirt] [PATCH 08/20] openvz: Use virDomainObjListFindBy{UUID|ID}Ref

For openvzDomObjFromDomainLocked and openvzDomainLookupByID let's return a locked and referenced @vm object so that callers can then use the common and more consistent virDomainObjEndAPI in order to handle cleanup rather than needing to know that the returned object is locked and calling

[libvirt] [PATCH 01/20] bhyve: Use virDomainObjListFindBy{UUID|ID}Ref

For bhyveDomObjFromDomain, bhyveDomainLookupByUUID, and bhyveDomainLookupByID let's return a locked and referenced @vm object so that callers can then use the common and more consistent virDomainObjEndAPI in order to handle cleanup rather than needing to know that the returned object is locked and

[libvirt] [PATCH 10/20] uml: Add more specific error message on failed FindBy call

Rather than an empty failed to find, let's provide a bit more knowledge about what we failed to find by using the name string or the id value. Signed-off-by: John Ferlan --- src/uml/uml_driver.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[libvirt] [PATCH 02/20] libxl: Fix possible deadlock in libxlDomainMigrateBegin3Params

Commit id '45697fe5' added a check for "Domain-0" to generate an error during libxlDomainMigrateBegin3Params; however, by returning NULL, the @vm was left locked since libxlDomObjFromDomain returns a locked @vm. Signed-off-by: John Ferlan --- src/libxl/libxl_driver.c | 7

[libvirt] [PATCH 07/20] openvz: Add more descriptive error message on Find failure

If openvzDomainLookupByID or openvzDomainLookupByName fails to find a vm, let's be a bit more descriptive by providing the failing id or name in the error message. Signed-off-by: John Ferlan --- src/openvz/openvz_driver.c | 10 ++ 1 file changed, 6 insertions(+), 4

Re: [libvirt] [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

Hi, > For OVMF (x86), I guess the initial set of properties should come from > the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list > might grow or change incompatibly over time, so this is just a raw > starter idea.) > (0) ARCH (one of IA32, IA32X64, X64) -- the bitnesses of

[libvirt] [PATCH] m4: use pkgconfig to detect xenstore

Since Xen 4.9 a pkgconfig file exists to gather info about building against libxenstore.so. Use it if available. Signed-off-by: Olaf Hering --- m4/virt-driver-xen.m4 | 41 + 1 file changed, 29 insertions(+), 12 deletions(-) diff --git

[libvirt] [PATCH] qemu: Add qemu functions for storage source private data handling

The qemu driver registered the helpers from util code, but it will be necessary to format also some qemu-specific data. Signed-off-by: Peter Krempa --- This patch conflicts with Michal's persistent reservations series. I'll need the code in the place this patch places it

[libvirt] [PATCH 0/8] Add optional pSeries features (HTM)

Applies cleanly on top of 90d7262552e8de3b067239b215903144a285723d. Patch 2/8 is fairly big because of all the capabilities data being added: I'm sending a redacted version to the list, the rest of the code can be grabbed from https://github.com/andreabolognani/libvirt/tree/pseries-caps

[libvirt] [PATCH 8/8] news: Update for the HTM pSeries feature

Signed-off-by: Andrea Bolognani --- docs/news.xml | 9 + 1 file changed, 9 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index a51ca973e4..fc56f776ae 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -35,6 +35,15 @@ + + +

[libvirt] [PATCH 3/8] qemu: Add capability for qom-list-properties

Signed-off-by: Andrea Bolognani --- src/qemu/qemu_capabilities.c | 4 +++- src/qemu/qemu_capabilities.h | 1 + tests/qemucapabilitiesdata/caps_2.12.0-gicv2.aarch64.xml | 1 +

Re: [libvirt] [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

On 03/09/18 15:27, Gerd Hoffmann wrote: > Hi, > >> For OVMF (x86), I guess the initial set of properties should come from >> the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list >> might grow or change incompatibly over time, so this is just a raw >> starter idea.) > >> (0)

[libvirt] [PATCH 2/8] tests: Add capabilities data for QEMU 2.12

Signed-off-by: Andrea Bolognani --- .../caps_2.12.0-gicv2.aarch64.replies | 17145 +++ .../caps_2.12.0-gicv2.aarch64.xml | 318 + .../caps_2.12.0-gicv3.aarch64.replies | 17145 +++

[libvirt] [PATCH 1/8] tests: Rename pseries-features-hpt test

We're going to use the same test case to exercise all optional pSeries features, so a more generic name is needed. Signed-off-by: Andrea Bolognani --- .../{pseries-features-hpt.args => pseries-features.args} | 0 .../{pseries-features-hpt.xml =>

[libvirt] [PATCH 7/8] qemu: Implement the HTM pSeries feature

This is the first in a list of pSeries-specific optional features that have recently been introduced in QEMU. Along with the feature proper, some generic code that will make it easier to implement subsequent features is introduced as well. Signed-off-by: Andrea Bolognani ---

[libvirt] [PATCH 4/8] qemu: Rename virQEMUCapsObjectProps* -> virQEMUCapsDeviceProps*

In QOM, all devices are objects, which makes the existing names technically correct; however, not all objects are devices, and soon we're going to start looking for object properties in addition to device properties: the former need to go through a different code path, so we need to be able to

[libvirt] [PATCH 5/8] qemu: Extract generic part from qemuMonitorJSONGetDeviceProps()

Querying properties for devices and objects is identical except for the specific QMP command that needs to be called. Take the existing qemuMonitorJSONGetDeviceProps(), scrub all the device-specific parts, thus turning it into the generic helper qemuMonitorJSONGetProps(), which is then used to

[libvirt] [PATCH 6/8] qemu: Add capability for the HTM pSeries feature

This is the first capability that depends on an object property, so we need to introduce a couple new functions at the same time. Signed-off-by: Andrea Bolognani --- src/qemu/qemu_capabilities.c | 38 + src/qemu/qemu_capabilities.h

Re: [libvirt] [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

On 03/09/18 12:27, Kashyap Chamarthy wrote: > On Thu, Mar 08, 2018 at 09:47:27PM +0100, Laszlo Ersek wrote: >> On 03/08/18 16:47, Daniel P. Berrangé wrote: >>> On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote: > > [...] > For OVMF (x86), I guess the initial set of properties

Re: [libvirt] [PATCH 1/8] tests: Rename pseries-features-hpt test

On Fri, 2018-03-09 at 16:07 +0100, Andrea Bolognani wrote: > We're going to use the same test case to exercise all optional > pSeries features, so a more generic name is needed. > > Signed-off-by: Andrea Bolognani > --- > .../{pseries-features-hpt.args =>

Re: [libvirt] [PATCH v7 02/11] qemu: Validate PCI controller options (modelName)

On 03/08/2018 08:34 AM, Andrea Bolognani wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1483816 > > Signed-off-by: Andrea Bolognani > --- > src/qemu/qemu_domain.c | 226 > +++-- > 1 file changed, 142 insertions(+), 84

Re: [libvirt] [PATCH v7 04/11] qemu: Validate PCI controller options (targetIndex)

On 03/08/2018 08:34 AM, Andrea Bolognani wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1483816 > > Signed-off-by: Andrea Bolognani Reviewed-by: Laine Stump -- libvir-list mailing list libvir-list@redhat.com

Re: [libvirt] [PATCH v7 00/11] qemu: Validate PCI controller options

On 03/08/2018 08:34 AM, Andrea Bolognani wrote: > Applies cleanly on top of b932ed69f6664f42e211bdde84c8ab04e1f19033. > > Patches 2/11 and 4/11 are the only ones missing R-bs, everything > else hasn't been significantly altered since [v5]. This all looks good now. I replied to 2 & 4 with R-b's.