qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/1] hw/block/nvme: fix assert on invalid irq vector


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 0/1] hw/block/nvme: fix assert on invalid irq vector
Date: Tue, 9 Jun 2020 16:18:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 6/9/20 4:14 PM, Kevin Wolf wrote:
> Am 09.06.2020 um 13:46 hat Klaus Jensen geschrieben:
>> On Jun  9 13:17, Philippe Mathieu-Daudé wrote:
>>> On 6/9/20 11:45 AM, Klaus Jensen wrote:
>>>> From: Klaus Jensen <k.jensen@samsung.com>
>>>>
>>>> I goofed up with commit c09794fe40e3 ("hw/block/nvme: allow use of any
>>>> valid msix vector").
>>>
>>> Kevin, since your queue isn't merged, can you directly squash the fix?
>>
>> The commit (c09794fe40e3) can just be dropped without conflicts, but it
>> leaves a use of n->params.num_queues in nvme_create_cq() which commit
>> cde74bfd4b87 ("hw/block/nvme: add max_ioqpairs device parameter") must
>> fix.
> 
> Hm, so it seems this isn't easy to squash in without conflicts (and I
> would have to rewrite the whole commit message), so I think it's better
> to just apply the series on top.
> 
> One problem with the commit message is that it references commit IDs
> which aren't stable yet. Maybe it's best if I apply these patches,
> manually fix up the commit ID references and then immediately do a pull
> request so that they become stable.

This is the friendlier way.

Less friendly way is to drop Klaus's patches and ask him to respin.
While this is a valid outcome, if we can avoid it it will save all of us
review time.

> 
> It would be good to have at least one review, though.

Maxim catched this issue, I'd feel safer if he acks your pre-merge queue.

> 
> Kevin
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]