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: Klaus Jensen
Subject: Re: [PATCH 0/1] hw/block/nvme: fix assert on invalid irq vector
Date: Tue, 9 Jun 2020 20:38:40 +0200

On Jun  9 17:32, Kevin Wolf wrote:
> Am 09.06.2020 um 16:18 hat Philippe Mathieu-Daudé geschrieben:
> > 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.
> 
> If Klaus wants to do that, fine with me. I'm just trying to find the
> easiest solution for all of us.
> 

Sure, I can respin it. I would like to include this series as well
though since I think it's a nice addition.

I'll post a v7 that includes Philippes's return value verification patch
as well as the patches in this series. We should only need a review or
two on those patches then.



reply via email to

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