qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH v2] hw/nvme: clean up CC register write logic


From: Klaus Jensen
Subject: Re: [PATCH v2] hw/nvme: clean up CC register write logic
Date: Tue, 7 Jun 2022 13:23:36 +0200

On Jun  7 13:06, Łukasz Gieryk wrote:
> On Fri, Jun 03, 2022 at 10:24:51PM +0200, Klaus Jensen wrote:
> > On Jun  1 15:28, Lukasz Maniak wrote:
> > > On Wed, May 25, 2022 at 09:35:24AM +0200, Klaus Jensen wrote:
> > > > 
> > > > +        stl_le_p(&n->bar.intms, 0);
> > > > +        stl_le_p(&n->bar.intmc, 0);
> > > > +        stl_le_p(&n->bar.cc, 0);
> > > 
> > > Looks fine, though it seems the NVMe spec says the above registers
> > > should be cleared during each reset for VF as well.
> > > 
> > 
> > Aren't the values of all other registers than CSTS just undefined? (NVMe
> > v2.0b, Section 8.26.3)
> 
> My 2 cents –
> 
> When VF is online:
> - Both Controller Reset (CR) and PCIe Function Level Reset (FLR) can be
>   issued to given VF
> - Both resets shall return all (except specific) Nvme registers of given
>   VF to their reset values (3.7.2)
> 
> When VF is offline:
> - CR cannot be issued (only CSTS is defined, writes to CC are dropped),
>   so doesn’t need an explicit IF
> - FLR is allowed as it’s a part of the procedure to bring VF online
>   (mentioned in 8.26.3)
> - At least FLR shall reset the registers for VF
> 
> So I agree with the other Lukasz's suggestion. I would also clear
> intms/intmc/cc for both: VF and PF reset paths, regardless of the actual
> reset type.
> 

Alright thanks - sounds good.

See v3.

Attachment: signature.asc
Description: PGP signature


reply via email to

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