Re: [EXT] Re: [PATCH] hw/cxl: Add support for abort of background operation

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Thu, 15 Aug 2024 18:04:03 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Mon, 12 Aug 2024 13:04:36 -0700
> Davidlohr Bueso <dave@stgolabs.net> wrote:
> 
> > On Wed, 07 Aug 2024, ajay.opensrc wrote:\n  
> > >>From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> > >>So to my reading if you elect not to stop because it's very
> > >>nearly done, or indeed it raced and the command is done,
> > >>the specification doesn't tell us what to return.
> > >>That operation supports abort, we just didn't.
> > >>
> > >>What do you think should happen here?    
> > 
> > I had interpreted this case to return success for the req abort
> > command, but the caller had to check the Mailbox Status register
> > to see if result had actually canceled the on going bg op.
> > And I don't think there's a race between checking the status
> > register and the on-going bg command completing. Aborting
> > means percentage complete < 100 && bg field cleared.  
> I'm fine with it returning success, but I'm didn't read the spec
> as actually saying it would. Maybe I missed something as these
> cases where a call is a noop are classic corner cases where it
> might return
> a) you are crazy, why did you call that?
> b) sure I'll do nothing.

Clarification received was indeed that the device should return
success to a BG command abort if there isn't one to abort.

So that's easy :)

Jonathan
> 
> > 
> > Jonathan, would you want the patch to have an arbitrary "don't
> > abort the bg op over 85% done"? I see this useful as it allows
> > the cancel a bit more versatility, albeit potentially getting
> > in the way of testing. What do you think?  
> I'd not bother - I think we will cancel very rarely in reality.
> This is mostly a route around possible really long delays, not
> a tool for normal operation.
> >   
> > >
> > >IMHO, device should ignore the abort command and
> > >most likely return "Unsupported" code (since, the spec is not
> > >clear on what should be the return code in case the command
> > >is ignored). Does it make sense?    
> > 
> > I don't think so. This is not an error imo. This case is about
> > supporting the request abort command, but the actual command
> > not actually triggering the desired cancel.
> >   
> > >
> > >Agree that it's a spec hole and may need to be clarified.    
> > 
> > Yes, it would be nice to have this case be explicitly stated.
> > And it is not even a corner case, the way the spec describes
> > it, this case can perfectly happen.  
> Absolutely. I'll poke the relevant person.,
> 
> Jonathan
> 
> > 
> > Thanks,
> > Davidlohr  
> 
>