On Apr 11 07:54, Christoph Hellwig wrote:
> 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.
> 

Right.

> 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.
> 

Are you referring to -device nvme-ns "syntax"? Using -device nvme, you
cannot set uuid.

> 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.

Luckily we can do that easier now since we moved away from the Intel id
(which got rid of a bunch of quirks at that time).

I'll see what we can come up with to fix this properly in QEMU.

Thanks for looking into it.