Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
On Mon, 8 Jan 2024, Alex Williamson wrote: On Mon, 8 Jan 2024 23:32:04 +0530 (IST) Vivek Kashyap wrote: On Mon, 8 Jan 2024, Alex Williamson wrote: On Mon, 8 Jan 2024 18:42:19 +0530 (IST) Vivek Kashyap wrote: ... As I've stated above, for libvirt we should consider only passing it via the 'secret' object. Sounds good. Will follow this up. Alex - will you be working on the qemu update? I'm not the one driving a use case that requires libvirt support for vf-token. Thanks, Not asking wrt libvirt but queried wrt qemu due to your original implementation in qemu: https://lore.kernel.org/lkml/20200204161737.34696...@w520.home https://github.com/qemu/qemu/commit/2dca1b37a7605abb135559ef1b0d63929e7ae60d Per the first link: NB. It's unclear whether there's value to this QEMU support without further exposure of SR-IOV within a VM. This is meant mostly as a test case where the real initial users will likely be DPDK drivers. I didn't author the commit in the second link. Based on the above comment it's clear that QEMU, or any VMM use case, was not the initial target for vf-token support. It was intended for DPDK, which already has a pretty low security model. QEMU was only a proof of concept with a code base more familiar to me. I also noted in the above my expectation that SR-IOV would be the legitimate use case in QEMU. My thought there was that QEMU would set a private vf-token and emulate an SR-IOV capability to the guest. Enabling SR-IOV by the guest would trigger a call-out to libvirt to effect the change via host pci-sysfs and attach the resulting VFs back to the VM. The vf-token would remain private and act as a measure of protection against other use cases for the VFs. I've never been strongly in favor of general vf-token support in QEMU. If a VF requires a vf-token, then by definition the PF is being managed by another vfio userspace driver. Somebody needs to decide whether that userspace driver is trustworthy since it may have access to all the data accessible to the VF. An in-kernel PF driver would be trusted by default, so what's the underlying motivation to make vf-token support more ubiquitous through the stack? In my view, this support attempts to de-emphasize the security risk of a 3rd party userspace PF driver while also promoting their very existence. I won't deny that use cases for this exist, but I have yet to see evidence that those are use cases I care to promote. So no, I won't be implementing a secret object implementation of this in QEMU. Thanks, Thanks for the explanation. I'll follow-up on the secret object implementation. -vk Alex ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
On Mon, 8 Jan 2024 23:32:04 +0530 (IST) Vivek Kashyap wrote: > On Mon, 8 Jan 2024, Alex Williamson wrote: > > > On Mon, 8 Jan 2024 18:42:19 +0530 (IST) > > Vivek Kashyap wrote: > > > >> ... > As I've stated above, for libvirt we should consider only passing it via > the 'secret' object. > >> > >> Sounds good. Will follow this up. > >> > >> Alex - will you be working on the qemu update? > > > > I'm not the one driving a use case that requires libvirt support for > > vf-token. Thanks, > > Not asking wrt libvirt but queried wrt qemu due to your original > implementation in qemu: > > https://lore.kernel.org/lkml/20200204161737.34696...@w520.home > https://github.com/qemu/qemu/commit/2dca1b37a7605abb135559ef1b0d63929e7ae60d Per the first link: NB. It's unclear whether there's value to this QEMU support without further exposure of SR-IOV within a VM. This is meant mostly as a test case where the real initial users will likely be DPDK drivers. I didn't author the commit in the second link. Based on the above comment it's clear that QEMU, or any VMM use case, was not the initial target for vf-token support. It was intended for DPDK, which already has a pretty low security model. QEMU was only a proof of concept with a code base more familiar to me. I also noted in the above my expectation that SR-IOV would be the legitimate use case in QEMU. My thought there was that QEMU would set a private vf-token and emulate an SR-IOV capability to the guest. Enabling SR-IOV by the guest would trigger a call-out to libvirt to effect the change via host pci-sysfs and attach the resulting VFs back to the VM. The vf-token would remain private and act as a measure of protection against other use cases for the VFs. I've never been strongly in favor of general vf-token support in QEMU. If a VF requires a vf-token, then by definition the PF is being managed by another vfio userspace driver. Somebody needs to decide whether that userspace driver is trustworthy since it may have access to all the data accessible to the VF. An in-kernel PF driver would be trusted by default, so what's the underlying motivation to make vf-token support more ubiquitous through the stack? In my view, this support attempts to de-emphasize the security risk of a 3rd party userspace PF driver while also promoting their very existence. I won't deny that use cases for this exist, but I have yet to see evidence that those are use cases I care to promote. So no, I won't be implementing a secret object implementation of this in QEMU. Thanks, Alex ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
On Mon, 8 Jan 2024, Alex Williamson wrote: On Mon, 8 Jan 2024 18:42:19 +0530 (IST) Vivek Kashyap wrote: ... As I've stated above, for libvirt we should consider only passing it via the 'secret' object. Sounds good. Will follow this up. Alex - will you be working on the qemu update? I'm not the one driving a use case that requires libvirt support for vf-token. Thanks, Not asking wrt libvirt but queried wrt qemu due to your original implementation in qemu: https://lore.kernel.org/lkml/20200204161737.34696...@w520.home https://github.com/qemu/qemu/commit/2dca1b37a7605abb135559ef1b0d63929e7ae60d thanks vk Alex ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
On Mon, 8 Jan 2024 18:42:19 +0530 (IST) Vivek Kashyap wrote: > ... > >> As I've stated above, for libvirt we should consider only passing it via > >> the 'secret' object. > > Sounds good. Will follow this up. > > Alex - will you be working on the qemu update? I'm not the one driving a use case that requires libvirt support for vf-token. Thanks, Alex ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
... As I've stated above, for libvirt we should consider only passing it via the 'secret' object. Sounds good. Will follow this up. Alex - will you be working on the qemu update? Forgot to add: If you need a way to test it with a libvirt-started VM in the interim until the qemu commandline configuration accepts secrets (which should be fairly trivial, and we will accept patches based on qemu code which was pushed but not released yet) you can use device-property overrides: https://libvirt.org/drvqemu.html#overriding-properties-of-qemu-devices note that it has the same implications about supportability as using commandline overrides: https://libvirt.org/drvqemu.html#pass-through-of-arbitrary-qemu-commands Thanks for the pointer. Will try it out. -vk ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
On Mon, Jan 08, 2024 at 12:44:01 +0100, Peter Krempa wrote: > On Mon, Jan 08, 2024 at 17:05:45 +0530, Vivek Kashyap wrote: > > > > > > If there is even a slight expectation of confidentiality (IMO just > > > calling it a 'secret' in documentation is enough to justify that > > > expectation) it should be treated as such. > > > > > > Thus qemu needs to add the possibility to pass it via the 'secret' > > > object, so that libvirt can pass it encrypted. On the device commandline > > > we'll just pass the alias to the secret. > > > > > > There's a well documented and maintained way to do that so it should be > > > a very straightforward and quick modification. > > > > > > > Until then the problem is that we are unable to launch the VMs when the > > > > PF > > > > is in the uesrspace. For now this patch is only bridging the gap to qemu > > > > commandline. > > > > > > The above should be done prior doing this in libvirt so that we can use > > > the new approach without having any duplicate code. > > > > > > > Yes, that sounds good. We need to add the mechanism to pass the vf-token via > > a secret object. However, until it is done we are unable to proceed with our > > VMs with PF in the userspace unless we provide the vf-token as in this > > series. > > > > So for now either a) the qemu commit needs to be revert (so that we can > > continue without > >providing vf-token uuid), OR > > b) We add libvirt support for clear-text vf-token, then add the choice to > >qemu to additionally provide the vf-token via a secret object and then > >update libvirt to pass the encrypted secret. > > As I've stated above, for libvirt we should consider only passing it via > the 'secret' object. Forgot to add: If you need a way to test it with a libvirt-started VM in the interim until the qemu commandline configuration accepts secrets (which should be fairly trivial, and we will accept patches based on qemu code which was pushed but not released yet) you can use device-property overrides: https://libvirt.org/drvqemu.html#overriding-properties-of-qemu-devices note that it has the same implications about supportability as using commandline overrides: https://libvirt.org/drvqemu.html#pass-through-of-arbitrary-qemu-commands ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
On Mon, Jan 08, 2024 at 17:05:45 +0530, Vivek Kashyap wrote: > > > > If there is even a slight expectation of confidentiality (IMO just > > calling it a 'secret' in documentation is enough to justify that > > expectation) it should be treated as such. > > > > Thus qemu needs to add the possibility to pass it via the 'secret' > > object, so that libvirt can pass it encrypted. On the device commandline > > we'll just pass the alias to the secret. > > > > There's a well documented and maintained way to do that so it should be > > a very straightforward and quick modification. > > > > > Until then the problem is that we are unable to launch the VMs when the PF > > > is in the uesrspace. For now this patch is only bridging the gap to qemu > > > commandline. > > > > The above should be done prior doing this in libvirt so that we can use > > the new approach without having any duplicate code. > > > > Yes, that sounds good. We need to add the mechanism to pass the vf-token via > a secret object. However, until it is done we are unable to proceed with our > VMs with PF in the userspace unless we provide the vf-token as in this series. > > So for now either a) the qemu commit needs to be revert (so that we can > continue without >providing vf-token uuid), OR > b) We add libvirt support for clear-text vf-token, then add the choice to >qemu to additionally provide the vf-token via a secret object and then >update libvirt to pass the encrypted secret. As I've stated above, for libvirt we should consider only passing it via the 'secret' object. ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
If there is even a slight expectation of confidentiality (IMO just calling it a 'secret' in documentation is enough to justify that expectation) it should be treated as such. Thus qemu needs to add the possibility to pass it via the 'secret' object, so that libvirt can pass it encrypted. On the device commandline we'll just pass the alias to the secret. There's a well documented and maintained way to do that so it should be a very straightforward and quick modification. Until then the problem is that we are unable to launch the VMs when the PF is in the uesrspace. For now this patch is only bridging the gap to qemu commandline. The above should be done prior doing this in libvirt so that we can use the new approach without having any duplicate code. Yes, that sounds good. We need to add the mechanism to pass the vf-token via a secret object. However, until it is done we are unable to proceed with our VMs with PF in the userspace unless we provide the vf-token as in this series. So for now either a) the qemu commit needs to be revert (so that we can continue without providing vf-token uuid), OR b) We add libvirt support for clear-text vf-token, then add the choice to qemu to additionally provide the vf-token via a secret object and then update libvirt to pass the encrypted secret. -vk ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
On Wed, Jan 03, 2024 at 22:42:41 +0530, Vivek Kashyap wrote: > > > On Tue, 2 Jan 2024, Alex Williamson wrote: > > > 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? > > The level of confidentiality has been left open in the vf-token > implementation across kernel and qemu. Perhaps we need to find a way to > allow a higher level solution to restrict/tighten it further based on a > policy. I don't immediately have a suggestion on how. If there is even a slight expectation of confidentiality (IMO just calling it a 'secret' in documentation is enough to justify that expectation) it should be treated as such. Thus qemu needs to add the possibility to pass it via the 'secret' object, so that libvirt can pass it encrypted. On the device commandline we'll just pass the alias to the secret. There's a well documented and maintained way to do that so it should be a very straightforward and quick modification. > Until then the problem is that we are unable to launch the VMs when the PF > is in the uesrspace. For now this patch is only bridging the gap to qemu > commandline. The above should be done prior doing this in libvirt so that we can use the new approach without having any duplicate code. ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
On Tue, 2 Jan 2024, Alex Williamson wrote:
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?
The level of confidentiality has been left open in the vf-token
implementation across kernel and qemu. Perhaps we need to find a way to
allow a higher level solution to restrict/tighten it further based on
a policy. I don't immediately have a suggestion on how.
Until then the problem is that we are unable to launch the VMs when the PF
is in the uesrspace. For now this patch is only bridging the gap to qemu
commandline.
-vk
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:
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
Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
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
[ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
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
[vf-token 0/8] Introduce vf-token when using userspace PF
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:
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
