Re: [PATCH 4/4] nvme: check that EUI/GUID/UUID are globally unique

[Christoph Hellwig <hch@lst.de>]

On Mon, Apr 11, 2022 at 07:05:33AM +0200, Christoph Hellwig wrote:
> > However, what I'm seeing seems to show that the uuid is same uuid as
> > well when not using -device nvme-ns but just -device nvme (this is
> > called legacy now it seems?) without the uuid set you end up in the
> > situation I described. I just destroyed my guests and started from
> > scratch a set up using qemu-system-x86_64 v6.2.0 on debian-testing,
> > and end up in a different situation but it is still a bit perplexing.
> 
> With my usual qemu test setup (built from a git a few weeks ago), no
> uuid shows up unless explicitly set.

Digging a bit deeper this was "fixed" by:

5f4884c4412318a1adc105dea9cc28f7625ce730
Author: Klaus Jensen <k.jensen@samsung.com>
Date:   Mon Aug 9 12:34:40 2021 +0200

    hw/nvme: fix missing variable initializers

    Coverity found that 'uuid', 'csi' and 'eui64' are uninitialized.
    While we set most of the fields, we do not explicitly set the rsvd2
    field in the NvmeIdNsDescr header.
		         
    Fix this by explicitly zero-initializing the variables.

Note that even with the fix the uuid field is always reported, even
when it shouldn't - it just is that Linux handles a 0 UUID gracefully.

I can also not find any code that would assign a different uuid
when using a different command line syntax, but given how unusable
the new syntax is I've not actually been able to try it.

So I think for now we'll just need to disable identifier on qemu.

It would be great if qemu could switch to a new PCI ID after this is
fixed as that simplifies the quirking.