From: Klaus Jensen <k.jensen@samsung.com>

Hi Peter,

The commit message on the patch describes the issue. This is a QEMU
crashing bug in -rc4 that I introduced early in the cycle and never
found in time. Lack of testing device hotplugging is the cause for that.

I'm not sure what to say other than I'm terribly sorry for introducing
this and if this means an -rc5 needs to be rolled, then I'm even more
sorry.

I think an acceptance test could have caught this, and I am already
working on an acceptance test suite for the nvme device, so I'll add
something that test this as well. But, well, it doesn't help now.

Klaus Jensen (1):
  hw/block/nvme: fix invalid msix exclusive uninit

 hw/block/nvme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.31.1

On Apr 22 15:58, Klaus Jensen wrote:
>From: Klaus Jensen <k.jensen@samsung.com>
>
>Hi Peter,
>
>The commit message on the patch describes the issue. This is a QEMU
>crashing bug in -rc4 that I introduced early in the cycle and never
>found in time. Lack of testing device hotplugging is the cause for that.
>
>I'm not sure what to say other than I'm terribly sorry for introducing
>this and if this means an -rc5 needs to be rolled, then I'm even more
>sorry.
>
>I think an acceptance test could have caught this, and I am already
>working on an acceptance test suite for the nvme device, so I'll add
>something that test this as well. But, well, it doesn't help now.
>
>Klaus Jensen (1):
>  hw/block/nvme: fix invalid msix exclusive uninit
>
> hw/block/nvme.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>-- 
>2.31.1
>
>

As far as I can tell, to cause this crash, monitor access is required, 
so I am not sure if we can get away with a note on this in the release 
notes and fix this in a potential stable release or next.

On Thu, 22 Apr 2021 at 15:07, Klaus Jensen <its@irrelevant.dk> wrote:
>
> On Apr 22 15:58, Klaus Jensen wrote:
> >From: Klaus Jensen <k.jensen@samsung.com>
> >
> >Hi Peter,
> >
> >The commit message on the patch describes the issue. This is a QEMU
> >crashing bug in -rc4 that I introduced early in the cycle and never
> >found in time. Lack of testing device hotplugging is the cause for that.
> >
> >I'm not sure what to say other than I'm terribly sorry for introducing
> >this and if this means an -rc5 needs to be rolled, then I'm even more
> >sorry.
> >
> >I think an acceptance test could have caught this, and I am already
> >working on an acceptance test suite for the nvme device, so I'll add
> >something that test this as well. But, well, it doesn't help now.

> As far as I can tell, to cause this crash, monitor access is required,
> so I am not sure if we can get away with a note on this in the release
> notes and fix this in a potential stable release or next.

Is this a regression since 5.2 ?

thanks
-- PMM

On Apr 22 19:58, Peter Maydell wrote:
>On Thu, 22 Apr 2021 at 15:07, Klaus Jensen <its@irrelevant.dk> wrote:
>>
>> On Apr 22 15:58, Klaus Jensen wrote:
>> >From: Klaus Jensen <k.jensen@samsung.com>
>> >
>> >Hi Peter,
>> >
>> >The commit message on the patch describes the issue. This is a QEMU
>> >crashing bug in -rc4 that I introduced early in the cycle and never
>> >found in time. Lack of testing device hotplugging is the cause for that.
>> >
>> >I'm not sure what to say other than I'm terribly sorry for introducing
>> >this and if this means an -rc5 needs to be rolled, then I'm even more
>> >sorry.
>> >
>> >I think an acceptance test could have caught this, and I am already
>> >working on an acceptance test suite for the nvme device, so I'll add
>> >something that test this as well. But, well, it doesn't help now.
>
>> As far as I can tell, to cause this crash, monitor access is required,
>> so I am not sure if we can get away with a note on this in the release
>> notes and fix this in a potential stable release or next.
>
>Is this a regression since 5.2 ?
>

Yes.