[libvirt] [PATCH v1 24/31] qemu: Create NVMe disk in domain namespace

Michal Privoznik mprivozn at redhat.com
Fri Aug 2 15:19:53 UTC 2019


On 7/16/19 4:37 PM, Peter Krempa wrote:
> On Thu, Jul 11, 2019 at 17:54:11 +0200, Michal Privoznik wrote:
>> If a domain has an NVMe disk configured, then we need to create
>> /dev/vfio/* paths in domain's namespace so that qemu can open
>> them.
>>
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>> ---
>>   src/qemu/qemu_domain.c | 35 ++++++++++++++++++++++++++++++++++-
>>   1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
>> index 949bbace88..cd3205a588 100644
>> --- a/src/qemu/qemu_domain.c
>> +++ b/src/qemu/qemu_domain.c
>> @@ -11831,7 +11831,8 @@ qemuDomainGetHostdevPath(virDomainDefPtr def,
>>   
>>                   perm = VIR_CGROUP_DEVICE_RW;
>>                   if (teardown) {
>> -                    if (!virDomainDefHasVFIOHostdev(def))
>> +                    if (!virDomainDefHasVFIOHostdev(def) &&
>> +                        !virDomainDefHasNVMeDisk(def))
> 
> As said previously I don't like this construct and also this hunk feels
> really that it does not belong to this patch.

The thing is that NVMe disks are both hostdevs and disks. So whenever we 
deal with /dev/vfio/* we have to consider both.

One solution that comes to my mind is to take /dev/vfio/vfio completely 
out of the picture on qemuDomainGetHostdevPath() and 
qemuDomainGetNVMeDiskIOMMUGroupPaths() levels, have them return a single 
path that device is associated with (/dev/vfio/N) and let caller do 
checks then if /dev/vfio/vfio must also be included in whatever it is 
they want to do.

Michal




More information about the libvir-list mailing list