Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF

2024-01-02 Thread Alex Williamson 
On Tue,  2 Jan 2024 18:55:10 +0530
Vivek Kashyap  wrote:

> The VFIO PCI ABI has been extended to require userspace PF driver to set 
> a VF token to a known value. The VF drivers are then required to provide
> this token to access the VF device. The vf-token is set by the PF driver
> before VF drivers can access the device. The kernel provides no means to
> retrieve the token in use; but there is no specification describing the 
> distribution or level of confidentiality of the token.

At the same time, both the kernel and this series indicate the token is
a shared secret, which is the reason the kernel provides no means to
access the token.  Is it reasonable to have a secret shared token in
xml, logs, and QEMU command line?  The token is shared between all VFs
associated to a PF, so as this support more formally moves from a QEMU
one-off hack to libvirt support, are we revealing a secret by promoting
this model?

Furthermore, libvirt has always been able to consider the vfio-pci
device trusted, at least so far as it's provided by a kernel driver.
With VF token support, the VF driver itself may still be a kernel
driver, but the PF is managed via a userspace driver with unknown
capabilities relative to the integrity of the VF device.  I don't know
if we need to or how we take into account that lack of device
authentication.  Certainly without some degree of attestation of the PF
driver and VF token, or potentially a mechanism for a more
cryptographic statement of trust, such a device ought not to be
involved with a confidential VM.

I'm not sure what needs to be done here, maybe the device level trust
is a problem for a higher level management tool, but I'd like to take a
more thoughtful look at the implications of VF token support as we move
up the stack rather than position this as simply filling a gap in QEMU
vfio-pci support.  Thanks,

Alex

> Qemu has been 
> extended to require the vf-token when vf device is used. An important 
> point to note is that the vf-token is required only when both the PF and
> VF are used in userspace. 
> 
> This patch series adds support to provide the vf-token (uuid format) in the
> domain XML and to generate the qemu commandline including the vf-token.
> 
> To support vf-token the new element will be used as follows:
>
>   
>   
> 
> 
> 
>   
>   function='0x0'/>
> 
> 
> The generated commandline will include the following:
> 
> -device {"driver":"vfio-pci","host":":00:0.1",
>  "vf-token":"00112233-4455-6677-8899-aabbccddeeff",
>  "id":"hostdev0","bus":"pci.0","addr":"0x1"}
> 
> Changes since initial RFC based on review comments received:
> 1. Added documentation
> 2. Added test cases and ran successful test suite after each patch commit
> 3. fixed spaces, coding sytle, and uuid string format 
> 4. Used S:vftoken in virJSONValueObjectAdd instead of a conditional
> 
> Vivek Kashyap (8):
>   Define the vf-token extension for PCI device
>   Introduce the vf-token qemu capability
>   This patch introduces the PCI address extension flag for vf-token
>   This patch introduces new XML parser/formatter functions for parsing
> the vf-token
>   Introduce a validation function for vf-token support in qemu and
> generate vf-token device attribute in qemu command line
>   Provide information about the vf-token flag
>   Add tests for the vf-token flag to the qemuxml2argv and qemuxml2xml
> test suites
>   Update news about vf-token
> 
>  NEWS.rst  |  8 +++
>  docs/formatdomain.rst |  3 ++
>  src/conf/device_conf.c| 49 ---
>  src/conf/domain_addr.h|  1 +
>  src/conf/domain_conf.c|  8 +++
>  src/conf/schemas/basictypes.rng   |  7 +++
>  src/libvirt_private.syms  |  1 +
>  src/qemu/qemu_capabilities.c  |  3 ++
>  src/qemu/qemu_capabilities.h  |  1 +
>  src/qemu/qemu_command.c   |  8 +++
>  src/qemu/qemu_domain_address.c|  3 ++
>  src/qemu/qemu_validate.c  | 20 
>  src/util/virpci.c |  7 +++
>  src/util/virpci.h | 10 
>  .../qemucapabilitiesdata/caps_8.1.0_s390x.xml |  1 +
>  .../caps_8.1.0_x86_64.xml |  1 +
>  .../caps_8.2.0_x86_64.xml |  1 +
>  .../hostdev-vfio-vf-token.x86_64-latest.args  | 34 +
>  .../hostdev-vfio-vf-token.xml | 22 +
>  tests/qemuxml2argvtest.c  |  1 +
>  .../hostdev-vfio-vf-token.x86_64-latest.xml   | 40 +++
>  tests/qemuxml2xmltest.c   |  1 +
>  22 files changed, 223 insertions(+), 7 deletions(-)
>  create mode 100644 
> tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args
>  create mode 100644

Re: Re: [libvirt PATCH 3/5] Config some capabilities for loongarch virt machine

2024-01-02 Thread Andrea Bolognani 
On Tue, Dec 19, 2023 at 11:52:03AM +0800, lixianglai wrote:
> > So does loongarch actually have ioapic support? Just making sure. I'm
> > surprised because apparently no other non-x86 architecture supports
> > it...
>
> Yes, loongarch does have IOAPIC, but this feature has no effect on loongarch
> at this stage, I will cut it first to simplify the committed code.
>
> In addition, I have a question, if I understand correctly, the IOAPIC here
> should be the device interrupt controller, which is located in the bridge
> chip,
>
> it is called IOAPIC under x86, PCH_PIC under loongarch, and GIC under arm.
>
> The kernel_irqchip attribute of the machine parameter in qemu corresponding
> to the function VIR_DOMAIN_FEATURE_IOAPIC determines
>
> whether the device interrupt controller is simulated in qemu or kvm. So arm
> also has such a need, but why doesn't arm add?

Okay, so x86's IOAPIC is controlled by the  element, while
Arm's GIC uses the  element. By that logic, loongarch should
probably introduce a  element.

It's a bit silly that we need a separate element per architecture,
especially considering that most of the time we just want to control
the kernel_irqchip flag. Case in point, as you noticed Arm doesn't
expose the ability to configure that at the moment.

On the other hand, additional arch-features might show up in the
future, at which point the separate element would start making sense.
See GIC for an example.

Overall, if you don't have a pressing need to expose the ability to
control the kernel_irqchip flag I would just avoid doing anything
about it now and leave the decision for another day and, possibly,
person :)

-- 
Andrea Bolognani / Red Hat / Virtualization
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

Re: Re: [libvirt PATCH 0/5] add loongarch support for libvirt

2024-01-02 Thread Andrea Bolognani 
On Mon, Dec 18, 2023 at 11:40:03AM +0800, lixianglai wrote:
> On Thu, Dec 14, 2023 at 02:08:44PM +0800, xianglai li wrote:
> > Great to see that edk2 support has already been mainlined! An
> > excellent next step would be to get an edk2-loongarch64 package into
> > the various distros... Please consider working with the maintainers
> > for edk2 in Fedora to make that happen, as it would significantly
> > lower the barrier for interested people to get involved.
>
> Yes, we will do that, currently the loongarch code is being moved from the
> edk2-platform directory to the edk2 directory,
>
> I think after this work is completed, we will have the edk2 installation
> package.

I'm not very familiar with how the edk2 repository is maintained, but
that sounds like a good plan. Presumably an edk2 release will have to
be tagged as well.

> > The /usr/share/qemu/ directory is owned by the QEMU package, and
> > other components should not drop their files in there. The exception
> > is the /usr/share/qemu/firmware/ directory, which is specifically
> > designed for interoperation.
> >
> > The edk2 files should be installed to /usr/share/edk2/loongarch64/,
> > following the convention established by existing architectures. Once
> > the directory name already contains architecture information, you can
> > use shorter and less unique names for the files themselves.
>
> I think edk2-loongarch64-code.fd can be the loongarch bios that comes with
> the qemu package,
>
> and then its installation path is  /usr/share/qemu which makes sense.

Yes, but distro packages usually strip those bits and rely on
firmware packages being installed separately instead.

It's just a minor point. As long as support is still being merged
into the various upstream projects, testing things out is always
going to be messy. It will naturally become smoother over time :)

> > The information provided in the cover letter, including pointers to
> > the various not-yet-upstreamed changes and instructions on how to
> > test everything, is very much appreciated!
>
> Ok, I will provide more detailed instructions on changes and testing in the
> next version.

Personally I think that the information related to testing that
you've provided in the cover letter is quite extensive, so don't feel
that you necessarily need to expand upon it.

-- 
Andrea Bolognani / Red Hat / Virtualization
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

Re: [PATCH] storage_util: Fix the false condition in virStorageBackendDeviceIsEmpty

2024-01-02 Thread Ján Tomko 

On a Wednesday in 2023, Han Han wrote:

In virStorageBackendDeviceIsEmpty, the return value for
virStorageBackendPARTEDValidLabel is -1 or 0. That makes the later
condition 'ret == -2' make always false. Remove the always false
condition.

Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.

Fixes: https://gitlab.com/libvirt/libvirt/-/issues/576



As Michal pointed out in the linked issue, the functions return -2 if
the functionality was not compiled in.

Jano


Signed-off-by: Han Han 
---
src/storage/storage_util.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)


signature.asc
Description: PGP signature
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

Re: Re: [libvirt PATCH 5/5] Add bios path for loongarch

2024-01-02 Thread Andrea Bolognani 
On Tue, Dec 19, 2023 at 07:44:02PM +0800, lixianglai wrote:
> > On Thu, Dec 14, 2023 at 02:08:49PM +0800, xianglai li wrote:
> > The way firmware is configured these days is through firmware
> > descriptor files. See src/qemu/qemu_firmware* and tests/qemufirmware*
> > for additional information, but the short version is that you want
> > your edk2 package to include something like this:
> >
> ># /usr/share/qemu/firmware/50-edk2-loongarch64.json
> >{
> >  "interface-types": [
> >"uefi"
> >  ],
> >  "mapping": {
> >"device": "flash",
> >"mode" : "split",
> >"executable": {
> >  "filename": "/usr/share/edk2/loongarch64/QEMU_CODE.fd",
> >  "format": "raw"
> >},
> >"nvram-template": {
> >  "filename": "/usr/share/edk2/loongarch64/QEMU_VARS.fd",
> >  "format": "raw"
> >}
> >  },
> >  "targets": [
> >{
> >  "architecture": "loongarch64",
> >  "machines": [
> >"virt",
> >"virt-*"
> >  ]
> >}
> >  ]
> >}
>
> Ok, I will remove the custom bios path and then try to add json in the qemu
> and edk2 installation packages.

Note that the JSON descriptor files in tests/qemufirmwaredata/ are
taken directly from the Fedora edk2 package, and in the long run we
want that to be the case for loongarch too, but you don't necessarily
need to wait for the firmware to be packaged in Fedora before
creating libvirt test cases. You can just have a file containing
reasonable-looking values, such as the ones I've shown above, to get
things going, and then we can replace it with the actual one for
Fedora at a later time.

The QEMU package itself doesn't ship any JSON descriptor files.

-- 
Andrea Bolognani / Red Hat / Virtualization
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

Re: Re: [libvirt PATCH 4/5] Implement the method of getting host info for loongarch

2024-01-02 Thread Andrea Bolognani 
On Tue, Dec 19, 2023 at 05:23:36PM +0800, lixianglai wrote:
> > On Thu, Dec 14, 2023 at 02:08:48PM +0800, xianglai li wrote:
> > > +++ b/src/util/virhostcpu.c
> > > @@ -579,7 +579,7 @@ virHostCPUParsePhysAddrSize(FILE *cpuinfo, unsigned 
> > > int *addrsz)
> > >   char *str;
> > >   char *endptr;
> > >
> > > -if (!(str = STRSKIP(line, "address sizes")))
> > > +if (!(str = STRCASESKIP(line, "address sizes")))
> > >   continue;
> >
> > So is the case different on loongarch than it is on other
> > architectures? Weird.
>
> Yes, loongarch and x86 do have some similarities and differences in the cpu
> Address space string, loongarch is "Address Sizes" under X86 is "address
> sizes",

Unfortunate choice on the kernel's part, but not much we can do about
that I guess. The way you handled it is perfectly fine.

> arm and other architectures should not have this identifier, At present,
> only x86 architecture and sh architecture can enter the process,
>
> other architectures will directly return, and the superior call also needs
> to allow the loongarch architecture. I will correct it in the next version

Good catch! I hadn't even noticed that but it definitely needs to be
addressed.

> > >   #elif !defined(WIN32) && \
> > >   (defined(__x86_64__) || \
> > >defined(__i386__) || \
> > > - defined(__amd64__))
> > > + defined(__amd64__) || \
> > > +defined(__loongarch__))
> > >   return virSysinfoReadDMI();
> >
> > Does loongarch actually have DMI support?
>
> Yes, loongarch does support dmi.

Excellent, just making sure :)

-- 
Andrea Bolognani / Red Hat / Virtualization
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

[PATCH vf-token 8/8] NEWS: Update news about vf-token

2024-01-02 Thread Vivek Kashyap 
Update news about vf-token

Signed-off-by: Vivek Kashyap 
---
 NEWS.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/NEWS.rst b/NEWS.rst
index dc40602c72..5e6a7c3147 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -17,6 +17,14 @@ v10.0.0 (unreleased)
 
 * **New features**
 
+  * qemu: support VF tokens for vfio-pci
+
+"vf-token",implemented as a UUID is part of VFIO PCI ABI, and acts as
+a shared key between vfio PF and VF drivers. The token is set by the
+PF driver and the VF driver provides it to access the VF. The
+vfio vf-token uuid is included in the VM XML specification for the pci
+device, and the token is passed in qemu commandline on VM launch.
+
 * **Improvements**
 
 * **Bug fixes**
-- 
2.33.8
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

[PATCH vf-token 7/8] test: add tests for the vf-token flag

2024-01-02 Thread Vivek Kashyap 
Add tests for the vf-token flag to the qemuxml2argv and qemuxml2xml
test suites

Signed-off-by: Vivek Kashyap 
Signed-off-by: Ciara Loftus 
---
 .../hostdev-vfio-vf-token.x86_64-latest.args  | 34 
 .../hostdev-vfio-vf-token.xml | 22 ++
 tests/qemuxml2argvtest.c  |  1 +
 .../hostdev-vfio-vf-token.x86_64-latest.xml   | 40 +++
 tests/qemuxml2xmltest.c   |  1 +
 5 files changed, 98 insertions(+)
 create mode 100644 
tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml
 create mode 100644 
tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml

diff --git a/tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args 
b/tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args
new file mode 100644
index 00..e449c84ea9
--- /dev/null
+++ b/tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args
@@ -0,0 +1,34 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1 \
+USER=test \
+LOGNAME=test \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.config \
+/usr/bin/qemu-system-x86_64 \
+-name guest=QEMUGuest1,debug-threads=on \
+-S \
+-object 
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-QEMUGuest1/master-key.aes"}'
 \
+-machine pc,usb=off,dump-guest-core=off,memory-backend=pc.ram,acpi=off \
+-accel tcg \
+-cpu qemu64 \
+-m size=219136k \
+-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":224395264}' \
+-overcommit mem-lock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-device 
'{"driver":"piix3-usb-uhci","id":"usb","bus":"pci.0","addr":"0x1.0x2"}' \
+-audiodev '{"id":"audio1","driver":"none"}' \
+-device 
'{"driver":"vfio-pci","host":":00:00.0","vf-token":"00112233-4455-6677-8899-aabbccddeeff","id":"hostdev0","bus":"pci.0","addr":"0x8"}'
 \
+-device 
'{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.0","addr":"0x2"}' \
+-sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml 
b/tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml
new file mode 100644
index 00..87762a
--- /dev/null
+++ b/tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml
@@ -0,0 +1,22 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219100
+  
+hvm
+
+  
+  
+/usr/bin/qemu-system-x86_64
+
+
+  
+  
+
+  
+
+  
+  
+
+  
+
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index b2ea2191dc..20bc914748 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1547,6 +1547,7 @@ mymain(void)
 DO_TEST_CAPS_LATEST_PARSE_ERROR("hostdev-pci-duplicate");
 DO_TEST_CAPS_LATEST("hostdev-vfio");
 DO_TEST_CAPS_LATEST("hostdev-vfio-multidomain");
+DO_TEST_CAPS_LATEST("hostdev-vfio-vf-token");
 DO_TEST_CAPS_LATEST("hostdev-mdev-precreated");
 DO_TEST_CAPS_LATEST_PARSE_ERROR("hostdev-mdev-src-address-invalid");
 DO_TEST_CAPS_LATEST_PARSE_ERROR("hostdev-mdev-invalid-target-address");
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml 
b/tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml
new file mode 100644
index 00..65c4fc6a4a
--- /dev/null
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml
@@ -0,0 +1,40 @@
+
+  QEMUGuest1
+  c7a5fdbd-edaf-9455-926a-d65c16db1809
+  219100
+  219100
+  1
+  
+hvm
+
+  
+  
+qemu64
+  
+  
+  destroy
+  restart
+  destroy
+  
+/usr/bin/qemu-system-x86_64
+
+
+  
+
+
+
+
+
+  
+  
+
+  
+
+  
+  
+
+
+  
+
+  
+
diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c
index 1010b68ebc..4b2c0e980a 100644
--- a/tests/qemuxml2xmltest.c
+++ b/tests/qemuxml2xmltest.c
@@ -432,6 +432,7 @@ mymain(void)
 DO_TEST_CAPS_LATEST("hostdev-pci-address-unassigned");
 DO_TEST_CAPS_LATEST("hostdev-pci-multifunction");
 DO_TEST_CAPS_LATEST("hostdev-vfio");
+DO_TEST_CAPS_LATEST("hostdev-vfio-vf-token");
 DO_TEST_CAPS_ARCH_LATEST("hostdev-vfio-zpci", "s390x");
 DO_TEST_CAPS_ARCH_LATEST("hostdev-vfio-zpci-multidomain-many", "s390x");
 DO_TEST_CAPS_ARCH_LATEST("hostdev-vfio-zpci-autogenerate", "s390x");
-- 
2.33.8
___
Devel mailing list --

[PATCH vf-token 6/8] docs: Update documentation and vf-token schema

2024-01-02 Thread Vivek Kashyap 
Provide information about the vf-token flag

Signed-off-by: Vivek Kashyap 
---
 docs/formatdomain.rst   | 3 +++
 src/conf/schemas/basictypes.rng | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 310d2bc427..29a7b3145e 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -3744,6 +3744,9 @@ control where on the bus the device will be placed:
between 0x0001 and 0x, inclusive), and ``fid`` (a hex value between
0x and 0x, inclusive) used by PCI devices on S390 for
User-defined Identifiers and Function Identifiers.
+   The ``vf-token`` element is supported in uuid format. The vf-token is a
+   shared secret between userspace vfio-pci PF driver and VF driver. The
+   token is set by the PF driver, and must be provided for VF access.
:since:`Since 1.3.5` , some hypervisor drivers may accept an
 element with no other attributes as an explicit
request to assign a PCI address for the device rather than some other type 
of
diff --git a/src/conf/schemas/basictypes.rng b/src/conf/schemas/basictypes.rng
index 26eb538077..bbb7484430 100644
--- a/src/conf/schemas/basictypes.rng
+++ b/src/conf/schemas/basictypes.rng
@@ -121,6 +121,13 @@
 
   
 
+
+ 
+   
+ 
+   
+ 
+
   
   
 
-- 
2.33.8
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

[PATCH vf-token 4/8] conf: XML parsing and formatting of vf-token

2024-01-02 Thread Vivek Kashyap 
This patch introduces new XML parser/formatter functions for
parsing the vf-token

Signed-off-by: Vivek Kashyap 
Signed-off-by: Ciara Loftus 
---
 src/conf/device_conf.c   | 49 ++--
 src/conf/domain_conf.c   |  8 +++
 src/libvirt_private.syms |  1 +
 src/util/virpci.c|  7 ++
 src/util/virpci.h|  2 ++
 5 files changed, 60 insertions(+), 7 deletions(-)

diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
index f3d977f2b7..f490aeef9a 100644
--- a/src/conf/device_conf.c
+++ b/src/conf/device_conf.c
@@ -70,6 +70,21 @@ virZPCIDeviceAddressParseXML(xmlNodePtr node,
 return 0;
 }
 
+
+static int
+virPCIDeviceTokenParseXML(xmlNodePtr node,
+  virPCIDeviceAddress *addr)
+{
+if (virXMLPropUUID(node, "uuid", VIR_XML_PROP_NONE,
+   addr->token.uuid) < 0)
+   return -1;
+
+addr->token.isSet = 1;
+
+return 0;
+}
+
+
 void
 virDomainDeviceInfoClear(virDomainDeviceInfo *info)
 {
@@ -200,6 +215,7 @@ virPCIDeviceAddressParseXML(xmlNodePtr node,
 virPCIDeviceAddress *addr)
 {
 xmlNodePtr zpci;
+xmlNodePtr token;
 
 memset(addr, 0, sizeof(*addr));
 
@@ -231,6 +247,11 @@ virPCIDeviceAddressParseXML(xmlNodePtr node,
 return -1;
 }
 
+if ((token = virXMLNodeGetSubelement(node, "vf-token"))) {
+   if (virPCIDeviceTokenParseXML(token, addr) < 0)
+   return -1;
+}
+
 return 0;
 }
 
@@ -239,13 +260,27 @@ virPCIDeviceAddressFormat(virBuffer *buf,
   virPCIDeviceAddress addr,
   bool includeTypeInAddr)
 {
-virBufferAsprintf(buf, "\n",
-  includeTypeInAddr ? "type='pci' " : "",
-  addr.domain,
-  addr.bus,
-  addr.slot,
-  addr.function);
+g_auto(virBuffer) attrBuf = VIR_BUFFER_INITIALIZER;
+g_auto(virBuffer) tokenBuf = VIR_BUFFER_INIT_CHILD(buf);
+virBuffer *tb = NULL;
+
+virBufferAsprintf(, " %sdomain='0x%04x' bus='0x%02x' "
+  "slot='0x%02x' function='0x%d'",
+   includeTypeInAddr ? "type='pci' " : "",
+   addr.domain,
+   addr.bus,
+   addr.slot,
+   addr.function);
+
+if (virPCIVFIOTokenIDIsPresent()) {
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+
+virBufferAsprintf(, "\n",
+  virUUIDFormat(addr.token.uuid, uuidstr));
+tb = 
+}
+
+virXMLFormatElement(buf, "address", , tb);
 }
 
 int
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 22ad43e1d7..8bda81815a 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -5403,6 +5403,14 @@ virDomainDeviceInfoFormat(virBuffer *buf,
   info->addr.pci.zpci.uid.value,
   info->addr.pci.zpci.fid.value);
 }
+
+if (virPCIVFIOTokenIDIsPresent(>addr.pci.token)) {
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+
+virBufferAsprintf(, "\n",
+  virUUIDFormat(info->addr.pci.token.uuid,
+uuidstr));
+}
 break;
 
 case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE:
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 31c0f169c3..b2bc26c323 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -3138,6 +3138,7 @@ virPCIHeaderTypeToString;
 virPCIIsVirtualFunction;
 virPCIStubDriverTypeFromString;
 virPCIStubDriverTypeToString;
+virPCIVFIOTokenIDIsPresent;
 virPCIVirtualFunctionListFree;
 virZPCIDeviceAddressIsIncomplete;
 virZPCIDeviceAddressIsPresent;
diff --git a/src/util/virpci.c b/src/util/virpci.c
index afce7b52b7..0a9ae7a881 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -2314,6 +2314,13 @@ virZPCIDeviceAddressIsPresent(const virZPCIDeviceAddress 
*addr)
 }
 
 
+bool
+virPCIVFIOTokenIDIsPresent(const virPCIDeviceToken *token)
+{
+return token->isSet;
+}
+
+
 void
 virPCIVirtualFunctionListFree(virPCIVirtualFunctionList *list)
 {
diff --git a/src/util/virpci.h b/src/util/virpci.h
index da32c2f4d2..8510752e84 100644
--- a/src/util/virpci.h
+++ b/src/util/virpci.h
@@ -271,6 +271,8 @@ int virPCIDeviceAddressParse(char *address, 
virPCIDeviceAddress *bdf);
 bool virZPCIDeviceAddressIsIncomplete(const virZPCIDeviceAddress *addr);
 bool virZPCIDeviceAddressIsPresent(const virZPCIDeviceAddress *addr);
 
+bool virPCIVFIOTokenIDIsPresent(const virPCIDeviceToken *token);
+
 int virPCIGetVirtualFunctionInfo(const char *vf_sysfs_device_path,
  int pfNetDevIdx,
  char **pfname,
-- 
2.33.8
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

[PATCH vf-token 5/8] qemu: Introduce validation for vf-token

2024-01-02 Thread Vivek Kashyap 
Introduce a validation function for vf-token support in qemu and
generate vf-token device attribute in qemu command line

Signed-off-by: Vivek Kashyap 
---
 src/qemu/qemu_command.c  |  8 
 src/qemu/qemu_validate.c | 20 
 2 files changed, 28 insertions(+)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 54fb8220e8..0e81a3ed73 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -4706,6 +4706,7 @@ qemuBuildPCIHostdevDevProps(const virDomainDef *def,
 virDomainNetTeamingInfo *teaming;
 g_autofree char *host = virPCIDeviceAddressAsString(>addr);
 const char *failover_pair_id = NULL;
+g_autofree char *token = NULL;
 
 /* caller has to assign proper passthrough backend type */
 switch (pcisrc->backend) {
@@ -4732,9 +4733,16 @@ qemuBuildPCIHostdevDevProps(const virDomainDef *def,
 teaming->persistent)
 failover_pair_id = teaming->persistent;
 
+if ((dev->info->pciAddrExtFlags & VIR_PCI_ADDRESS_EXTENSION_VFTOKEN) &&
+pcisrc->addr.token.isSet) {
+token = g_new0(char, VIR_UUID_STRING_BUFLEN);
+virUUIDFormat(pcisrc->addr.token.uuid, token);
+}
+
 if (virJSONValueObjectAdd(,
   "s:driver", "vfio-pci",
   "s:host", host,
+  "S:vf-token", token,
   "s:id", dev->info->alias,
   "p:bootindex", dev->info->effectiveBootIndex,
   "S:failover_pair_id", failover_pair_id,
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index e475ad035e..13114ca3d1 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -1364,6 +1364,24 @@ 
qemuValidateDomainDeviceDefZPCIAddress(virDomainDeviceInfo *info,
 }
 
 
+static int
+qemuValidateDomainDeviceDefVFTokenId(virDomainDeviceInfo *info,
+ virQEMUCaps *qemuCaps)
+{
+virPCIDeviceToken *vftoken = >addr.pci.token;
+
+if (virPCIVFIOTokenIDIsPresent(vftoken) &&
+!virQEMUCapsGet(qemuCaps, QEMU_CAPS_VFIO_VFTOKEN)) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+   "%s",
+   _("This QEMU binary doesn't support vf token ids"));
+return -1;
+}
+
+return 0;
+}
+
+
 static int
 qemuValidateDomainDeviceDefAddressDrive(virDomainDeviceInfo *info,
 const virDomainDef *def,
@@ -1483,6 +1501,8 @@ qemuValidateDomainDeviceDefAddress(const 
virDomainDeviceDef *dev,
 case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI:
 if (qemuValidateDomainDeviceDefZPCIAddress(info, qemuCaps) < 0)
 return -1;
+ if (qemuValidateDomainDeviceDefVFTokenId(info, qemuCaps) < 0)
+return -1;
 break;
 
 case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE:
-- 
2.33.8
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

[PATCH vf-token 3/8] conf: Define PCI address vf-token extension

2024-01-02 Thread Vivek Kashyap 
This patch introduces the PCI address extension flag for vf-token

Signed-off-by: Vivek Kashyap 
---
 src/conf/domain_addr.h | 1 +
 src/qemu/qemu_domain_address.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index e72fb48847..29e7257177 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -29,6 +29,7 @@
 typedef enum {
 VIR_PCI_ADDRESS_EXTENSION_NONE = 0, /* no extension */
 VIR_PCI_ADDRESS_EXTENSION_ZPCI = 1 << 0, /* zPCI support */
+VIR_PCI_ADDRESS_EXTENSION_VFTOKEN = 1 << 1, /* VF token support */
 } virPCIDeviceAddressExtensionFlags;
 
 typedef enum {
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 099778b2a8..3be5acbc9e 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -575,6 +575,9 @@ 
qemuDomainDeviceCalculatePCIAddressExtensionFlags(virQEMUCaps *qemuCaps,
 extFlags |= VIR_PCI_ADDRESS_EXTENSION_ZPCI;
 }
 
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VFIO_VFTOKEN))
+extFlags |= VIR_PCI_ADDRESS_EXTENSION_VFTOKEN;
+
 return extFlags;
 }
 
-- 
2.33.8
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

[PATCH vf-token 2/8] qemu: capabilities: Introduce QEMU_CAPS_VFIO_VFTOKEN

2024-01-02 Thread Vivek Kashyap 
Introduce the vf-token qemu capability

Signed-off-by: Vivek Kashyap 
---
 src/qemu/qemu_capabilities.c | 3 +++
 src/qemu/qemu_capabilities.h | 1 +
 tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml  | 1 +
 tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml | 1 +
 tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml | 1 +
 5 files changed, 7 insertions(+)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 83119e871a..f4cacd48d0 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -698,6 +698,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
   /* 450 */
   "run-with.async-teardown", /* QEMU_CAPS_RUN_WITH_ASYNC_TEARDOWN 
*/
   "virtio-blk-vhost-vdpa", /* 
QEMU_CAPS_DEVICE_VIRTIO_BLK_VHOST_VDPA */
+  "vf-token", /* QEMU_CAPS_VFIO_VFTOKEN */
 );
 
 
@@ -1385,6 +1386,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
 { "virtio-crypto-device", QEMU_CAPS_DEVICE_VIRTIO_CRYPTO },
 { "cryptodev-backend-lkcf", QEMU_CAPS_OBJECT_CRYPTO_LKCF },
 { "pvpanic-pci", QEMU_CAPS_DEVICE_PANIC_PCI },
+{ "vf-token", QEMU_CAPS_VFIO_VFTOKEN },
 };
 
 
@@ -1447,6 +1449,7 @@ static struct virQEMUCapsDevicePropsFlags 
virQEMUCapsDevicePropsVirtioSCSI[] = {
 };
 
 static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVfioPCI[] = {
+{ "vf-token", QEMU_CAPS_VFIO_VFTOKEN, NULL },
 };
 
 static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsSCSIDisk[] = {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 3c4f7f625b..f97b1c9fd5 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -677,6 +677,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for 
syntax-check */
 /* 450 */
 QEMU_CAPS_RUN_WITH_ASYNC_TEARDOWN, /* asynchronous teardown -run-with 
async-teardown=on|off */
 QEMU_CAPS_DEVICE_VIRTIO_BLK_VHOST_VDPA, /* virtio-blk-vhost-vdpa block 
driver */
+QEMU_CAPS_VFIO_VFTOKEN, /* vf-token support */
 
 QEMU_CAPS_LAST /* this must always be the last item */
 } virQEMUCapsFlags;
diff --git a/tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml 
b/tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml
index 427ee9d5c7..f4a65a133f 100644
--- a/tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml
+++ b/tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml
@@ -112,6 +112,7 @@
   
   
   
+  
   850
   39100245
   v8.0.0-1270-g1c12355b
diff --git a/tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml 
b/tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml
index d266dd0f31..202a2c7f8d 100644
--- a/tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml
@@ -198,6 +198,7 @@
   
   
   
+  
   8001000
   43100245
   v8.1.0
diff --git a/tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml 
b/tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml
index ef3bd14597..24809ab70f 100644
--- a/tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml
@@ -199,6 +199,7 @@
   
   
   
+  
   8001050
   43100246
   v8.1.0-3111-gad6ef0a42e
-- 
2.33.8
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

[ PATCH vf-token 0/8] Introduce vf-token when using userspace PF

2024-01-02 Thread Vivek Kashyap 
The VFIO PCI ABI has been extended to require userspace PF driver to set 
a VF token to a known value. The VF drivers are then required to provide
this token to access the VF device. The vf-token is set by the PF driver
before VF drivers can access the device. The kernel provides no means to
retrieve the token in use; but there is no specification describing the 
distribution or level of confidentiality of the token.  Qemu has been 
extended to require the vf-token when vf device is used. An important 
point to note is that the vf-token is required only when both the PF and
VF are used in userspace. 

This patch series adds support to provide the vf-token (uuid format) in the
domain XML and to generate the qemu commandline including the vf-token.

To support vf-token the new element will be used as follows:
   
  
  



  
 


The generated commandline will include the following:

-device {"driver":"vfio-pci","host":":00:0.1",
 "vf-token":"00112233-4455-6677-8899-aabbccddeeff",
 "id":"hostdev0","bus":"pci.0","addr":"0x1"}

Changes since initial RFC based on review comments received:
1. Added documentation
2. Added test cases and ran successful test suite after each patch commit
3. fixed spaces, coding sytle, and uuid string format 
4. Used S:vftoken in virJSONValueObjectAdd instead of a conditional

Vivek Kashyap (8):
  Define the vf-token extension for PCI device
  Introduce the vf-token qemu capability
  This patch introduces the PCI address extension flag for vf-token
  This patch introduces new XML parser/formatter functions for parsing
the vf-token
  Introduce a validation function for vf-token support in qemu and
generate vf-token device attribute in qemu command line
  Provide information about the vf-token flag
  Add tests for the vf-token flag to the qemuxml2argv and qemuxml2xml
test suites
  Update news about vf-token

 NEWS.rst  |  8 +++
 docs/formatdomain.rst |  3 ++
 src/conf/device_conf.c| 49 ---
 src/conf/domain_addr.h|  1 +
 src/conf/domain_conf.c|  8 +++
 src/conf/schemas/basictypes.rng   |  7 +++
 src/libvirt_private.syms  |  1 +
 src/qemu/qemu_capabilities.c  |  3 ++
 src/qemu/qemu_capabilities.h  |  1 +
 src/qemu/qemu_command.c   |  8 +++
 src/qemu/qemu_domain_address.c|  3 ++
 src/qemu/qemu_validate.c  | 20 
 src/util/virpci.c |  7 +++
 src/util/virpci.h | 10 
 .../qemucapabilitiesdata/caps_8.1.0_s390x.xml |  1 +
 .../caps_8.1.0_x86_64.xml |  1 +
 .../caps_8.2.0_x86_64.xml |  1 +
 .../hostdev-vfio-vf-token.x86_64-latest.args  | 34 +
 .../hostdev-vfio-vf-token.xml | 22 +
 tests/qemuxml2argvtest.c  |  1 +
 .../hostdev-vfio-vf-token.x86_64-latest.xml   | 40 +++
 tests/qemuxml2xmltest.c   |  1 +
 22 files changed, 223 insertions(+), 7 deletions(-)
 create mode 100644 
tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml
 create mode 100644 
tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml

-- 
2.33.8
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

[PATCH vf-token 1/8] virpci: Define the vf-token extension for PCI device

2024-01-02 Thread Vivek Kashyap 
Define the vf-token extension for PCI device

Signed-off-by: Vivek Kashyap 
---
 src/util/virpci.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/util/virpci.h b/src/util/virpci.h
index bc7cb2329f..da32c2f4d2 100644
--- a/src/util/virpci.h
+++ b/src/util/virpci.h
@@ -50,6 +50,13 @@ struct _virZPCIDeviceAddress {
 /* Don't forget to update virPCIDeviceAddressCopy if needed. */
 };
 
+typedef struct _virPCIDeviceToken virPCIDeviceToken;
+
+struct _virPCIDeviceToken {
+unsigned char uuid[VIR_UUID_BUFLEN];
+bool isSet;
+};
+
 struct _virPCIDeviceAddress {
 unsigned int domain;
 unsigned int bus;
@@ -58,6 +65,7 @@ struct _virPCIDeviceAddress {
 virTristateSwitch multi;
 int extFlags; /* enum virPCIDeviceAddressExtensionFlags */
 virZPCIDeviceAddress zpci;
+virPCIDeviceToken token;
 /* Don't forget to update virPCIDeviceAddressCopy if needed. */
 };
 
-- 
2.33.8
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

Re: [PATCH v2] Improve error message in remoteGetUNIXSocket

2024-01-02 Thread Richard W.M. Jones 
On Thu, Dec 21, 2023 at 03:48:30PM +0100, Martin Kletzander wrote:
> By adding a link to an explanation in the kbase.
> 
> Signed-off-by: Martin Kletzander 
> ---
> v2:
> - Do not print first socket path
> - Add a kbase article explaining the details and solutions
> - Add a link to said article
> 
> v1:
> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/WGEVYM4MEYLEKUGNVOYTOFP66IVLWNGL/
> 
> .../kbase/failed_connection_after_install.rst | 58 +++
>  docs/kbase/index.rst  |  3 +
>  docs/kbase/meson.build|  1 +
>  src/remote/remote_sockets.c   |  2 +-
>  4 files changed, 63 insertions(+), 1 deletion(-)
>  create mode 100644 docs/kbase/failed_connection_after_install.rst
> 
> diff --git a/docs/kbase/failed_connection_after_install.rst 
> b/docs/kbase/failed_connection_after_install.rst
> new file mode 100644
> index ..cea57c460e10
> --- /dev/null
> +++ b/docs/kbase/failed_connection_after_install.rst
> @@ -0,0 +1,58 @@
> +
> +Libvirt does not work after installation
> +
> +
> +.. contents::
> +
> +TL;DR
> +=
> +
> +Most probably you want to start a virtqemud socket:
> +
> +::
> +
> +   # systemctl start virtqemud.socket
> +
> +If you are unsure whether to do this, please read the rest of this document.
> +
> +Symptom
> +===
> +
> +After installing libvirt or a virt tool that uses libvirt, commands do
> +not work when run as root:
> +
> +::
> +
> +   # virsh list
> +   error: failed to connect to the hypervisor
> +   error: Operation not supported: Cannot use direct socket mode if no URI 
> is set.
> +   For more information see 
> https://libvirt.org/kbase/failed_connection_after_install.html
> +
> +Root cause
> +==
> +
> +Distribution guidelines and/or configurations may discourage or prohibit
> +starting services as part of a package installation.  And because libvirt 
> cannot
> +know where you might want to connect it cannot start it on its own.
> +
> +Solution
> +
> +
> +After installing libvirt you may need to start a particular libvirt daemon on
> +the local machine, set a (default) URI to connect to or, alternatively,
> +rebooting the machine might work.
> +
> +If you are trying to connect to a remote libvirt daemon you need to specify 
> a `connection URI <../uri.html>`__.
> +
> +If you are trying to control a local hypervisor, then the solution depends 
> on various factors. You should know:
> +
> +- what hypervisor driver you want to connect to, whether it is ``virtqemud`` 
> for QEMU, ``virtchd`` for Cloud Hypervisor, etc. and
> +- how to start a service or socket (in case of systemd) on you system.
> +
> +Example of the most common solution, trying to use QEMU/KVM on Linux with 
> systemd as an init system, is:
> +
> +::
> +
> +   # systemctl start virtqemud.socket
> +
> +also provided on the top of the page.
> diff --git a/docs/kbase/index.rst b/docs/kbase/index.rst
> index 896ececdf258..e51b35cbfce5 100644
> --- a/docs/kbase/index.rst
> +++ b/docs/kbase/index.rst
> @@ -64,6 +64,9 @@ Usage
>  `Secure Boot `__
>  Enable and disable the Secure Boot feature
>  
> +`Connection fail after installation `__
> +Explanation of a common issue users stumble upon after installation
> +
>  
>  Debugging
>  -
> diff --git a/docs/kbase/meson.build b/docs/kbase/meson.build
> index 5b608293e27c..6d4ca90215a5 100644
> --- a/docs/kbase/meson.build
> +++ b/docs/kbase/meson.build
> @@ -2,6 +2,7 @@ docs_kbase_files = [
>'backing_chains',
>'debuglogs',
>'domainstatecapture',
> +  'failed_connection_after_install',
>'index',
>'kvm-realtime',
>'launch_security_sev',
> diff --git a/src/remote/remote_sockets.c b/src/remote/remote_sockets.c
> index 4ab3d72933e2..8d403b6f014a 100644
> --- a/src/remote/remote_sockets.c
> +++ b/src/remote/remote_sockets.c
> @@ -398,7 +398,7 @@ remoteGetUNIXSocket(remoteDriverTransport transport,
>  
>  if (!direct_sock_name) {
>  virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
> -   _("Cannot use direct socket mode if no URI is 
> set"));
> +   _("Cannot use direct socket mode if no URI is 
> set. For more information see 
> https://libvirt.org/kbase/failed_connection_after_install.html;));
>  return NULL;
>  }
>  
> -- 

This is really good, thanks.

Reviewed-by: Richard W.M. Jones 


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org