Re: [PATCH 20/36] lib: Introduce virDomainFDAssociate API

On Thu, Jan 05, 2023 at 05:30:09PM +0100, Peter Krempa wrote: > The API can be used to associate one or more (e.g. a RO and RW fd for a > disk backend image) FDs to a VM. They can be then used per definition. > > The primary use case for now is for complex deployment where > libvirtd/virtqemud may be run inside a container and getting the image > into the container is complicated. > > In the future it will also allow passing e.g. vhost FDs and other > resources to a VM without the need to have a filesystem representation > for it. > > Passing raw FDs has few intricacies and thus libvirt will by default not > restore security labels. > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com&gt; > --- > include/libvirt/libvirt-domain.h | 22 ++++++++ > src/driver-hypervisor.h | 8 +++ > src/libvirt-domain.c | 82 +++++++++++++++++++++++++++++ > src/libvirt_public.syms | 5 ++ > src/remote/remote_daemon_dispatch.c | 40 ++++++++++++++ > src/remote/remote_driver.c | 27 ++++++++++ > src/remote/remote_protocol.x | 14 ++++- > src/remote_protocol-structs | 6 +++ > 8 files changed, 203 insertions(+), 1 deletion(-) > > diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h > index 295fd30c93..a1e39f2f70 100644 > --- a/include/libvirt/libvirt-domain.h > +++ b/include/libvirt/libvirt-domain.h > @@ -6457,4 +6457,26 @@ int virDomainStartDirtyRateCalc(virDomainPtr domain, > int seconds, > unsigned int flags); > > + > +/** > + * virDomainFDAssociateFlags: > + * > + * Since: 9.0.0 > + */ > +typedef enum { > + /* Attempt a best-effort restore of security labels after use (Since: 9.0.0) */ > + VIR_DOMAIN_FD_ASSOCIATE_SECLABEL_RESTORE = (1 << 0), > + /* Require mandatory restore of security labels after use (Since: 9.0.0) */ > + VIR_DOMAIN_FD_ASSOCIATE_SECLABEL_RESTORE_REQUIRE = (1 << 1), > + /* Use a seclabel allowing writes for the FD even if usage implies read-only mode (Since: 9.0.0) */ > + VIR_DOMAIN_FD_ASSOCIATE_SECLABEL_WRITABLE = (1 << 2), > +} virDomainFDAssociateFlags; Do we need to introduce flag that is not supported by any hypervisor? It should be perfectly fine to introduce the flag once there is actual usage for it or am I missing something?