[Qemu-devel] Subject: Re: [PATCH] hw/block/nvme

[Qemu-devel] Subject: Re: [PATCH] hw/block/nvme

[Toe Dev]

Hey,
While reviewing I noticed maybe we need to update the spec revision.
In: nvme_class_init(...)

current code  pc->revision=2
change to: pc->revision=3
However not really important I think.. Just for consistency.
When I done reviewing, should it be patched too, How?

Re: [Qemu-devel] Subject: Re: [PATCH] hw/block/nvme

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Tue, Sep 10, 2019 at 11:23:50PM +0300, Toe Dev wrote:
> Hey,
> While reviewing I noticed maybe we need to update the spec revision.
> In: nvme_class_init(...)
> 
> current code  pc->revision=2
> change to: pc->revision=3
> However not really important I think.. Just for consistency.
> When I done reviewing, should it be patched too, How?

The NVMe specification declares the PCI Revision ID field implementation
specific.  It doesn't seem to be a reflection of the NVMe specification
supported by the device.

If there is a PCI Vendor 0x8086 Device 0x5845 in the real world with
revision = 3 that we now emulate correctly, then it could be updated.

However, for live migration compatibility QEMU must keep old
guest-visible behavior too.  It's not as simple as changing the revision
value to 3, because then existing VMs migrating from an old QEMU to a
new QEMU would suddenly see the hardware change beneath them.

QEMU has the "machine types" mechanism to deal with this.  QEMU 4.2 and
later machine types (e.g. "pc-q35-4.2") would use revision = 3 while
older machine types would use revision = 2.  This maintains live
migration compatibility.

In summary, there is probably no strong reason to change this (although
I'm not an NVMe expert so maybe I've missed something).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]