Re: [libvirt] [PATCH v1 11/31] conf: Format and parse NVMe type disk

On 7/11/19 6:05 PM, Peter Krempa wrote: > On Thu, Jul 11, 2019 at 17:53:58 +0200, Michal Privoznik wrote: > > To simplify implementation, some restrictions are added. For > > instance, an NVMe disk can't go to any bus but virtio and has to > > be type of 'disk' and can't have startupPolicy set. > > > > Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; > > --- > > src/conf/domain_conf.c | 129 +++++++++++++++++++++++++ > > src/libvirt_private.syms | 1 + > > src/qemu/qemu_block.c | 1 + > > src/qemu/qemu_command.c | 1 + > > src/qemu/qemu_driver.c | 4 + > > src/qemu/qemu_migration.c | 1 + > > src/util/virstoragefile.c | 59 +++++++++++ > > src/util/virstoragefile.h | 15 +++ > > src/xenconfig/xen_xl.c | 1 + > > tests/qemuxml2argvdata/disk-nvme.xml | 12 ++- > > tests/qemuxml2xmloutdata/disk-nvme.xml | 1 + > > tests/qemuxml2xmltest.c | 1 + > > 12 files changed, 224 insertions(+), 2 deletions(-) > > create mode 120000 tests/qemuxml2xmloutdata/disk-nvme.xml > > > > diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c > > index 3323c9a5b1..73f5e1fa0f 100644 > > --- a/src/conf/domain_conf.c > > +++ b/src/conf/domain_conf.c > > @@ -5088,6 +5088,11 @@ virDomainDiskDefPostParse(virDomainDiskDefPtr disk, > > return -1; > > } > > + if (disk->src->type == VIR_STORAGE_TYPE_NVME) { > > + if (disk->src->nvme->managed == VIR_TRISTATE_BOOL_ABSENT) > > + disk->src->nvme->managed = VIR_TRISTATE_BOOL_YES; > > + } > > + > > if (disk->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE && > > virDomainDiskDefAssignAddress(xmlopt, disk, def) < 0) { > > return -1; > > @@ -5938,6 +5943,38 @@ virDomainDiskDefValidate(const virDomainDiskDef *disk) > > return -1; > > } > > + if (disk->src->type == VIR_STORAGE_TYPE_NVME) { > > Note that this can potentially happen in the backing chain as well, so > this should be checked throughout the whole backing chain. Is that so? I mean, other checks done in this funtion check only 'top level' disk->src too.

> > Also this seems all to belong to the qemu specific post parse callback. Possibly. But since other drivers would still use virNVMeDevice module I'm adding later in this series, and since the module is build on these assumptions I figured the best place to check for them is in driver agnostic callback.