Re: [PATCH v15 11/16] cxl: Validate and synchronize HDM ranges around reset

[Srirangan Madhavan]

On 10/26/26 8:25 PM, Alison Schofield wrote:
> Hi Srirangan,
>
> Is above statement underselling the potential impact? The quiesce is
> cxl_rwsem.region held for write, so for the whole reset it also blocks
> region and decoder sysfs, region probe, poison list/inject/clear, sanitize
> and event record tracing, on every CXL device.
>
> Can the changelog say what it blocks and for how long?
>
> more below on the 'how long' ?
>
> snip
>
>
> > +static int cxl_reset_execute(struct pci_dev *pdev, int dvsec, u16 cap)
> > +{
> > +     int rc;
> > +
> > +     cxl_region_quiesce_lock();
> > +     rc = cxl_reset_quiesced(pdev, dvsec, cap);
> > +     cxl_region_quiesce_unlock();
> IIUC, this cxl_rwsem.region for write for the whole reset, including the
> Memory Clear wait, which can run to CXL_RESET_MAX_WAIT_MS (20 seconds) plus
> the cache flushes. That blocks all region activity, on every CXL device in
> the system, not just the one being reset. Does resetting one device need
> to stop all of it?
>
> snip



Thanks for pointing out the wider impact. I updated the changelog to 
describe the operations blocked across CXL devices and to distinguish 
the 20-second reset-wait cap from the full lock hold time.

I agree that the current approach does not establish that unrelated CXL 
devices need to be blocked. For v16 I have retained the global lock, 
because the current code has no narrower mechanism to exclude changes to 
the affected region and decoder state

One option I can think of is to mark the endpoint as resetting while 
holding the region lock, then release the lock during the reset wait. 
Region operations involving that endpoint would check the marker before 
changing state and return busy. After reset, we would reacquire the 
region lock to restore state and clear the marker.

Does that seem like the right approach here? Or is there anything 
simpler? I can either fold it into the reset series or add a follow up 
changes to reduce the scope of this lock.

--
Regards,
Srirangan