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

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

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.

> 
> 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