On Fri, May 30, 2025 at 03:26:55PM +0100, Jonathan Cameron wrote:
> On Tue, 20 May 2025 14:39:47 +0100
> Jonathan Cameron via <qemu-devel@nongnu.org> wrote:
> 
> > On Thu,  8 May 2025 00:00:56 +0000
> > anisa.su...@gmail.com wrote:
> > 
> > > From: Anisa Su <anisa...@samsung.com>
> > > 
> > > This patchset adds support for 6 FM API DCD Management commands 
> > > (0x5600-0x5605)
> > > according to the CXL r3.2 Spec. It is based on the following branch:
> > > https://gitlab.com/jic23/qemu/-/tree/cxl-2025-02-20.  
> > 
> > Nice work - this is very clean and well presented.
> > 
> > I would like Fan to take a look an provide some tags as DCD modeling in
> > QEMU is more in his area of expertise than mine!
> > 
> > I think this series is much more ready for upstream than much of
> > my staging cxl tree so I'll rebase it to go near the front.
> > 
> > Today I'm focused on getting test cases to Richard for the TCG issues but
> > after that I'll spin a new tree (probably pushed out under a name
> > that makes it clear there is a known nasty problem though!)
> 
> Anisa,
> 
> Ideally I'd like to get the majority of this upstream once you post
> a v3.  To do that I'd like to break the dependence on mctp_i2c in patch 2.
> These commands are equally valid via a switch-cci (and that path to the
> fm owned ld_mctpcci is already upstream).
> 
> If you could send it as two series. One of which sits on upstream and
> doesn't include the i2c_mctp part and the other of which is applied once
> that support is available in my tree that would be great. I'll squash
> the i2c_mctp part into the patch that adds support for that in the
> first place.
> 
> I'll deal with rebasing needed for other command introductions etc.
> 
> There are just enough open questions in this series that I haven't done
> this rework directly (though I did start doing it - hence the missing
> include note in one of the patches).
> 
> Thanks,
> 
Sounds good, will do :)

Thanks,
Anisa
> Jonathan
> > 
> > Jonathan
> > 
> > 
> > > 
> > > The code was tested with libcxlmi, which runs in the QEMU VM and sends 
> > > 56xxh
> > > commands to the device (QEMU emulated) through MCTP messages over I2C
> > > bus. To perform end-to-end tests, both MCTP and DCD support are needed
> > > for the kernel, so the needed MCTP patches are applied on top of Ira's DCD
> > > branch https://github.com/weiny2/linux-kernel/tree/dcd-v4-2024-12-11.
> > > 
> > > For the tests of commands 0x5600 (Get DCD Info), 0x5601 (Get Host DC 
> > > Region
> > > Config), and 0x5603 (Get DC Region Extent Lists), DCD kernel code is not 
> > > involved.
> > > The libcxlmi test program is used to send the command to the device and 
> > > results
> > > are collected and verified.
> > > 
> > > For command 0x5602 (Set DC Region Config): device creates an event record 
> > > with type
> > > DC_EVENT_REGION_CONFIG_UPDATED and triggers an interrupt to the host
> > > if the configuration changes as a result of the command. Currently, the 
> > > kernel
> > > version used to test this only supports Add/Release type events. Thus, 
> > > this
> > > request essentially gets ignored but did not cause problems besides the 
> > > host
> > > not knowing about the configuration change when tested.
> > > 
> > > For the command 0x5604 (Initiate DC Add) and 0x5605 (Initiate DC 
> > > Release), the
> > > tests involve libcxlmi test program (acting as the FM), kernel DCD
> > > code (host) and QEMU device. The test workflow follows that in cxl r3.2 
> > > section
> > > 7.6.7.6.5 and 7.6.7.6.6. More specifically, the tests involve following
> > > steps,
> > > 1. Start a VM with CXL topology: 
> > > https://github.com/moking/cxl-test-tool/blob/main/utils/cxl.py#L54.
> > > 2. Load the CXL related drivers in the VM;
> > > 3. Create a DC region for the DCD device attached.
> > > 4. add/release DC extents by sending 0x5604 and 0x5605 respectively 
> > > through
> > > the out-of-tree libcxlmi test program
> > > (https://github.com/anisa-su993/libcxlmi/blob/dcd_management_cmds/tests/test-fmapi.c).
> > > 5. Check and verify the extents by retrieving the extents list through
> > > command 0x5603 in the test program.
> > > 
> > > The remaining 3 commands in this series (0x5606-0x5608) are related to 
> > > tags
> > > and sharing, thus have not been implemented.
> > > 
> > > Changes
> > > ================================================================================
> > > v1 -> v2:
> > > 1. Feedback from Jonathan Cameron on v1
> > > Addressed general style concerns (newlines/spacing, minor refactoring, 
> > > etc.)
> > > 1.1. Changes Related to 0x5600 - FMAPI Get DCD Info
> > >     - Squashed prepatory patch adding supported_blk_sizes_bitmask
> > >     - Added new prepatory patch moving opcodes enum from 
> > > cxl-mailbox-utils.c to
> > >     new header file opcodes.h
> > >     Needed for the check in i2c_mctp_cxl.c to ensure the FMAPI Commands
> > >     (0x51 - 0x59) are bound with MCTP_MT_CXL_FMAPI. By moving the enum,
> > >     the hardcoded values (0x51, 0x59) can be replaced with their
> > >     enumerators.
> > >     - Bug fix to return Add/Release Extent Selection Policy bitmasks
> > >       correctly
> > > 1.2. Changes Related to 0x5601 - FMAPI Get Host Region Config
> > >     - Prepatory patch to add dsmas_flags to CXLDCRegion struct was 
> > > modified to
> > >     store the booleans dsmas_flags is made up of instead of copying it 
> > > from the
> > >     CDAT for that region. Values hardcoded for unsupported flags.
> > >     - Build the returned dsmas_flags from the new booleans.
> > > 1.3. Changes Related to 0x5602 - FMAPI Set DC Region Config
> > >     - Added locking for CXLDCRegion bitmap for the case that extents are 
> > > being
> > >     added/released via a different CCI than that of the FM-enabled CCI.
> > >     - Prepatory patch created for the above (quite short, can be squashed 
> > > if
> > >     preferred)
> > >     - Added a check to verify that the requested block_size is supported 
> > > by the
> > >     region by looking at region->supported_blk_sizes_bitmask
> > >     - Instead of event_record validity flag being cleared, set to 1
> > >     - Fixed bug of forgetting to update region->block_size
> > > 1.4. Changes Related to 0x5603 - FMAPI Get DC Region Extents
> > >     - Minor refactoring of loop filling in response payload extents
> > > 
> > > 2. Feedback from Fan Ni and Jonathan Cameron on v1
> > > 2.1. Changes Related to 0x5604 - FMAPI Initiate DC Add
> > >     - Remove redundant storage of extents in event_rec_exts
> > >     - Refactor event record creation into helper function for re-use by 
> > > release
> > >     - Return event_record.available_extents
> > >     (total_extents_available - num_pending - num_accepted) instead of
> > >     leaving it blank
> > > 2.2. Changes Related to 0x5605 - FMAPI Initiate DC Release
> > >     - Remove redundant storage of extents in event_rec_exts/redundant 2nd 
> > > loop
> > >     - Add #define for removal_policy_bitmask instead of hardcoding 0x7
> > > 
> > > Anisa Su (10):
> > >   cxl-mailbox-utils: Move opcodes enum to new header file
> > >   cxl-mailbox-utils: 0x5600 - FMAPI Get DCD Info
> > >   cxl/type3: Add dsmas_flags to CXLDCRegion struct
> > >   cxl-mailbox-utils: 0x5601 - FMAPI Get Host Region Config
> > >   cxl_events.h: Move definition for dynamic_capacity_uuid and enum for
> > >     DC event types
> > >   hw/cxl_type3: Add DC Region bitmap lock
> > >   cxl-mailbox-utils: 0x5602 - FMAPI Set DC Region Config
> > >   cxl-mailbox-utils: 0x5603 - FMAPI Get DC Region Extent Lists
> > >   cxl-mailbox-utils: 0x5604 - FMAPI Initiate DC Add
> > >   cxl-mailbox-utils: 0x5605 - FMAPI Initiate DC Release
> > > 
> > >  hw/cxl/cxl-mailbox-utils.c   | 649 +++++++++++++++++++++++++++++++----
> > >  hw/cxl/i2c_mctp_cxl.c        |   6 +-
> > >  hw/mem/cxl_type3.c           |  41 ++-
> > >  include/hw/cxl/cxl_device.h  |  24 ++
> > >  include/hw/cxl/cxl_events.h  |  15 +
> > >  include/hw/cxl/cxl_mailbox.h |   6 +
> > >  include/hw/cxl/cxl_opcodes.h |  72 ++++
> > >  7 files changed, 724 insertions(+), 89 deletions(-)
> > >  create mode 100644 include/hw/cxl/cxl_opcodes.h
> > >   
> > 
> > 
> 

Reply via email to