On Fri, Apr 05, 2024 at 06:44:52PM +0100, Jonathan Cameron wrote: > On Fri, 5 Apr 2024 12:07:45 -0400 > Gregory Price <gregory.pr...@memverge.com> wrote: > > > 3. (C) Upon Device receiving Release Dynamic Capacity Request > > a. check for a pending release request. If exists, error. > > Not sure that's necessary - can queue as long as the head > can track if the bits are in a pending release state. >
Yeah probably it's fine to just queue the event and everything downstream just handles it. > > b. check that the bits in the MHD bitmap are actually set > Good. > > > > function: qmp_cxl_process_dynamic_capacity > > > > 4. (D) Upon Device receiving Release Dynamic Capacity Response > > a. clear the bits in the mhd bitmap > > b. remove the pending request from the pending list > > > > function: cmd_dcd_release_dyn_cap > > > > Something to note: The MHD bitmap is essentially the same as the > > existing DCD extent bitmap - except that it is located in a shared > > region of memory (mmap file, shm, whatever - pick one). > > I think you will ideally also have a per head one to track head access > to the things offered by the mhd. > Generally I try not to duplicate state, reduces consistency problems. You do still need a shared memory state and a per-head state to capture per-head data, but the allocation bitmap is really device-global state. Either way you have a race condition when checking the bitmap during a memory access in the process of adding/releasing capacity - but that's more an indication of bad host behavior than it is of a bug in the implementatio of the emulated device. Probably we don't need to read-lock the bitmap (for access validation), only write-lock. My preference, for what it's worth, would be to have a single bitmap and have it be anonymous-memory for Single-head and file-backed for for Multi-head. I'll have to work out the locking mechanism. ~Gregory
