hw/cxl/cxl-mailbox-utils.c | 620 ++++++++++++++++++++++++++++++++++- hw/mem/cxl_type3.c | 633 +++++++++++++++++++++++++++++++++--- hw/mem/cxl_type3_stubs.c | 20 ++ include/hw/cxl/cxl_device.h | 81 ++++- include/hw/cxl/cxl_events.h | 18 + qapi/cxl.json | 69 ++++ 6 files changed, 1396 insertions(+), 45 deletions(-)
A git tree of this series can be found here (with one extra commit on top
for printing out accepted/pending extent list):
https://github.com/moking/qemu/tree/dcd-v7
v6->v7:
1. Fixed the dvsec range register issue mentioned in the the cover letter in v6.
Only relevant bits are set to mark the device ready (Patch 6). (Jonathan)
2. Moved the if statement in cxl_setup_memory from Patch 6 to Patch 4. (Jonathan)
3. Used MIN instead of if statement to get record_count in Patch 7. (Jonathan)
4. Added "Reviewed-by" tag to Patch 7.
5. Modified cxl_dc_extent_release_dry_run so the updated extent list can be
reused in cmd_dcd_release_dyn_cap to simplify the process in Patch 8. (Jørgen)
6. Added comments to indicate further "TODO" items in cmd_dcd_add_dyn_cap_rsp.
(Jonathan)
7. Avoided irrelevant code reformat in Patch 8. (Jonathan)
8. Modified QMP interfaces for adding/releasing DC extents to allow passing
tags, selection policy, flags in the interface. (Jonathan, Gregory)
9. Redesigned the pending list so extents in the same requests are grouped
together. A new data structure is introduced to represent "extent group"
in pending list. (Jonathan)
10. Added support in QMP interface for "More" flag.
11. Check "Forced removal" flag for release request and not let it pass through.
12. Removed the dynamic capacity log type from CxlEventLog definition in cxl.json
to avoid the side effect it may introduce to inject error to DC event log.
(Jonathan)
13. Hard coded the event log type to dynamic capacity event log in QMP
interfaces. (Jonathan)
14. Adding space in between "-1]". (Jonathan)
15. Some minor comment fixes.
The code is tested with similar setup and has passed similar tests as listed
in the cover letter of v5[1] and v6[2].
Also, the code is tested with the latest DCD kernel patchset[3].
[1] Qemu DCD patchset v5: https://lore.kernel.org/linux-cxl/20240304194331.1586191-1-nifan.cxl@gmail.com/T/#t
[2] Qemu DCD patchset v6: https://lore.kernel.org/linux-cxl/20240325190339.696686-1-nifan.cxl@gmail.com/T/#t
[3] DCD kernel patches: https://lore.kernel.org/linux-cxl/20240324-dcd-type2-upstream-v1-0-b7b00d623625@intel.com/T/#m11c571e21c4fe17c7d04ec5c2c7bc7cbf2cd07e3
Fan Ni (12):
hw/cxl/cxl-mailbox-utils: Add dc_event_log_size field to output
payload of identify memory device command
hw/cxl/cxl-mailbox-utils: Add dynamic capacity region representative
and mailbox command support
include/hw/cxl/cxl_device: Rename mem_size as static_mem_size for
type3 memory devices
hw/mem/cxl_type3: Add support to create DC regions to type3 memory
devices
hw/mem/cxl-type3: Refactor ct3_build_cdat_entries_for_mr to take mr
size instead of mr as argument
hw/mem/cxl_type3: Add host backend and address space handling for DC
regions
hw/mem/cxl_type3: Add DC extent list representative and get DC extent
list mailbox support
hw/cxl/cxl-mailbox-utils: Add mailbox commands to support add/release
dynamic capacity response
hw/cxl/events: Add qmp interfaces to add/release dynamic capacity
extents
hw/mem/cxl_type3: Add DPA range validation for accesses to DC regions
hw/cxl/cxl-mailbox-utils: Add superset extent release mailbox support
hw/mem/cxl_type3: Allow to release extent superset in QMP interface
hw/cxl/cxl-mailbox-utils.c | 620 ++++++++++++++++++++++++++++++++++-
hw/mem/cxl_type3.c | 633 +++++++++++++++++++++++++++++++++---
hw/mem/cxl_type3_stubs.c | 20 ++
include/hw/cxl/cxl_device.h | 81 ++++-
include/hw/cxl/cxl_events.h | 18 +
qapi/cxl.json | 69 ++++
6 files changed, 1396 insertions(+), 45 deletions(-)
--
2.43.0
On Thu, Apr 18, 2024 at 04:10:51PM -0700, nifan.cxl@gmail.com wrote: > A git tree of this series can be found here (with one extra commit on top > for printing out accepted/pending extent list): > https://github.com/moking/qemu/tree/dcd-v7 > > v6->v7: > > 1. Fixed the dvsec range register issue mentioned in the the cover letter in v6. > Only relevant bits are set to mark the device ready (Patch 6). (Jonathan) > 2. Moved the if statement in cxl_setup_memory from Patch 6 to Patch 4. (Jonathan) > 3. Used MIN instead of if statement to get record_count in Patch 7. (Jonathan) > 4. Added "Reviewed-by" tag to Patch 7. > 5. Modified cxl_dc_extent_release_dry_run so the updated extent list can be > reused in cmd_dcd_release_dyn_cap to simplify the process in Patch 8. (Jørgen) > 6. Added comments to indicate further "TODO" items in cmd_dcd_add_dyn_cap_rsp. > (Jonathan) > 7. Avoided irrelevant code reformat in Patch 8. (Jonathan) > 8. Modified QMP interfaces for adding/releasing DC extents to allow passing > tags, selection policy, flags in the interface. (Jonathan, Gregory) > 9. Redesigned the pending list so extents in the same requests are grouped > together. A new data structure is introduced to represent "extent group" > in pending list. (Jonathan) > 10. Added support in QMP interface for "More" flag. > 11. Check "Forced removal" flag for release request and not let it pass through. > 12. Removed the dynamic capacity log type from CxlEventLog definition in cxl.json > to avoid the side effect it may introduce to inject error to DC event log. > (Jonathan) > 13. Hard coded the event log type to dynamic capacity event log in QMP > interfaces. (Jonathan) > 14. Adding space in between "-1]". (Jonathan) > 15. Some minor comment fixes. > > The code is tested with similar setup and has passed similar tests as listed > in the cover letter of v5[1] and v6[2]. > Also, the code is tested with the latest DCD kernel patchset[3]. > > [1] Qemu DCD patchset v5: https://lore.kernel.org/linux-cxl/20240304194331.1586191-1-nifan.cxl@gmail.com/T/#t > [2] Qemu DCD patchset v6: https://lore.kernel.org/linux-cxl/20240325190339.696686-1-nifan.cxl@gmail.com/T/#t > [3] DCD kernel patches: https://lore.kernel.org/linux-cxl/20240324-dcd-type2-upstream-v1-0-b7b00d623625@intel.com/T/#m11c571e21c4fe17c7d04ec5c2c7bc7cbf2cd07e3 > added review to all patches, will hopefully be able to add a Tested-by tag early next week, along with a v1 RFC for MHD bit-tracking. We've been testing v5/v6 for a bit, so I expect as soon as we get the MHD code ported over to v7 i'll ship a tested-by tag pretty quick. The super-set release will complicate a few things but this doesn't look like a blocker on our end, just a change to how we track bits in a shared bit/bytemap. > > Fan Ni (12): > hw/cxl/cxl-mailbox-utils: Add dc_event_log_size field to output > payload of identify memory device command > hw/cxl/cxl-mailbox-utils: Add dynamic capacity region representative > and mailbox command support > include/hw/cxl/cxl_device: Rename mem_size as static_mem_size for > type3 memory devices > hw/mem/cxl_type3: Add support to create DC regions to type3 memory > devices > hw/mem/cxl-type3: Refactor ct3_build_cdat_entries_for_mr to take mr > size instead of mr as argument > hw/mem/cxl_type3: Add host backend and address space handling for DC > regions > hw/mem/cxl_type3: Add DC extent list representative and get DC extent > list mailbox support > hw/cxl/cxl-mailbox-utils: Add mailbox commands to support add/release > dynamic capacity response > hw/cxl/events: Add qmp interfaces to add/release dynamic capacity > extents > hw/mem/cxl_type3: Add DPA range validation for accesses to DC regions > hw/cxl/cxl-mailbox-utils: Add superset extent release mailbox support > hw/mem/cxl_type3: Allow to release extent superset in QMP interface > > hw/cxl/cxl-mailbox-utils.c | 620 ++++++++++++++++++++++++++++++++++- > hw/mem/cxl_type3.c | 633 +++++++++++++++++++++++++++++++++--- > hw/mem/cxl_type3_stubs.c | 20 ++ > include/hw/cxl/cxl_device.h | 81 ++++- > include/hw/cxl/cxl_events.h | 18 + > qapi/cxl.json | 69 ++++ > 6 files changed, 1396 insertions(+), 45 deletions(-) > > -- > 2.43.0 >
On Fri, Apr 19, 2024 at 02:24:36PM -0400, Gregory Price wrote: > On Thu, Apr 18, 2024 at 04:10:51PM -0700, nifan.cxl@gmail.com wrote: > > A git tree of this series can be found here (with one extra commit on top > > for printing out accepted/pending extent list): > > https://github.com/moking/qemu/tree/dcd-v7 > > > > v6->v7: > > > > 1. Fixed the dvsec range register issue mentioned in the the cover letter in v6. > > Only relevant bits are set to mark the device ready (Patch 6). (Jonathan) > > 2. Moved the if statement in cxl_setup_memory from Patch 6 to Patch 4. (Jonathan) > > 3. Used MIN instead of if statement to get record_count in Patch 7. (Jonathan) > > 4. Added "Reviewed-by" tag to Patch 7. > > 5. Modified cxl_dc_extent_release_dry_run so the updated extent list can be > > reused in cmd_dcd_release_dyn_cap to simplify the process in Patch 8. (Jørgen) > > 6. Added comments to indicate further "TODO" items in cmd_dcd_add_dyn_cap_rsp. > > (Jonathan) > > 7. Avoided irrelevant code reformat in Patch 8. (Jonathan) > > 8. Modified QMP interfaces for adding/releasing DC extents to allow passing > > tags, selection policy, flags in the interface. (Jonathan, Gregory) > > 9. Redesigned the pending list so extents in the same requests are grouped > > together. A new data structure is introduced to represent "extent group" > > in pending list. (Jonathan) > > 10. Added support in QMP interface for "More" flag. > > 11. Check "Forced removal" flag for release request and not let it pass through. > > 12. Removed the dynamic capacity log type from CxlEventLog definition in cxl.json > > to avoid the side effect it may introduce to inject error to DC event log. > > (Jonathan) > > 13. Hard coded the event log type to dynamic capacity event log in QMP > > interfaces. (Jonathan) > > 14. Adding space in between "-1]". (Jonathan) > > 15. Some minor comment fixes. > > > > The code is tested with similar setup and has passed similar tests as listed > > in the cover letter of v5[1] and v6[2]. > > Also, the code is tested with the latest DCD kernel patchset[3]. > > > > [1] Qemu DCD patchset v5: https://lore.kernel.org/linux-cxl/20240304194331.1586191-1-nifan.cxl@gmail.com/T/#t > > [2] Qemu DCD patchset v6: https://lore.kernel.org/linux-cxl/20240325190339.696686-1-nifan.cxl@gmail.com/T/#t > > [3] DCD kernel patches: https://lore.kernel.org/linux-cxl/20240324-dcd-type2-upstream-v1-0-b7b00d623625@intel.com/T/#m11c571e21c4fe17c7d04ec5c2c7bc7cbf2cd07e3 > > > > added review to all patches, will hopefully be able to add a Tested-by > tag early next week, along with a v1 RFC for MHD bit-tracking. > > We've been testing v5/v6 for a bit, so I expect as soon as we get the > MHD code ported over to v7 i'll ship a tested-by tag pretty quick. > > The super-set release will complicate a few things but this doesn't > look like a blocker on our end, just a change to how we track bits in a > shared bit/bytemap. > Hi Gregory, Thanks for reviewing the patches so quickly. No pressure, but look forward to your MHD work. :) Fan > > > > Fan Ni (12): > > hw/cxl/cxl-mailbox-utils: Add dc_event_log_size field to output > > payload of identify memory device command > > hw/cxl/cxl-mailbox-utils: Add dynamic capacity region representative > > and mailbox command support > > include/hw/cxl/cxl_device: Rename mem_size as static_mem_size for > > type3 memory devices > > hw/mem/cxl_type3: Add support to create DC regions to type3 memory > > devices > > hw/mem/cxl-type3: Refactor ct3_build_cdat_entries_for_mr to take mr > > size instead of mr as argument > > hw/mem/cxl_type3: Add host backend and address space handling for DC > > regions > > hw/mem/cxl_type3: Add DC extent list representative and get DC extent > > list mailbox support > > hw/cxl/cxl-mailbox-utils: Add mailbox commands to support add/release > > dynamic capacity response > > hw/cxl/events: Add qmp interfaces to add/release dynamic capacity > > extents > > hw/mem/cxl_type3: Add DPA range validation for accesses to DC regions > > hw/cxl/cxl-mailbox-utils: Add superset extent release mailbox support > > hw/mem/cxl_type3: Allow to release extent superset in QMP interface > > > > hw/cxl/cxl-mailbox-utils.c | 620 ++++++++++++++++++++++++++++++++++- > > hw/mem/cxl_type3.c | 633 +++++++++++++++++++++++++++++++++--- > > hw/mem/cxl_type3_stubs.c | 20 ++ > > include/hw/cxl/cxl_device.h | 81 ++++- > > include/hw/cxl/cxl_events.h | 18 + > > qapi/cxl.json | 69 ++++ > > 6 files changed, 1396 insertions(+), 45 deletions(-) > > > > -- > > 2.43.0 > >
On Fri, Apr 19, 2024 at 11:43:14AM -0700, fan wrote: > On Fri, Apr 19, 2024 at 02:24:36PM -0400, Gregory Price wrote: > > > > added review to all patches, will hopefully be able to add a Tested-by > > tag early next week, along with a v1 RFC for MHD bit-tracking. > > > > We've been testing v5/v6 for a bit, so I expect as soon as we get the > > MHD code ported over to v7 i'll ship a tested-by tag pretty quick. > > > > The super-set release will complicate a few things but this doesn't > > look like a blocker on our end, just a change to how we track bits in a > > shared bit/bytemap. > > > > Hi Gregory, > Thanks for reviewing the patches so quickly. > > No pressure, but look forward to your MHD work. :) > > Fan Starting to get into versioniong hell a bit, since the Niagara work was based off of jonathan's branch and the mhd-dcd work needs some of the extentions from that branch - while this branch is based on master. Probably we'll need to wait for a new cxl dated branch to try and sus out the pain points before we push an RFC. I would not want to have conflicting commits for something like this for example: https://lore.kernel.org/qemu-devel/20230901012914.226527-2-gregory.price@memverge.com/ We get merge conflicts here because this is behind that patch. So pushing up an RFC in this state would be mostly useless to everyone. ~Gregory
On Sat, 20 Apr 2024 16:35:46 -0400 Gregory Price <gregory.price@memverge.com> wrote: > On Fri, Apr 19, 2024 at 11:43:14AM -0700, fan wrote: > > On Fri, Apr 19, 2024 at 02:24:36PM -0400, Gregory Price wrote: > > > > > > added review to all patches, will hopefully be able to add a Tested-by > > > tag early next week, along with a v1 RFC for MHD bit-tracking. > > > > > > We've been testing v5/v6 for a bit, so I expect as soon as we get the > > > MHD code ported over to v7 i'll ship a tested-by tag pretty quick. > > > > > > The super-set release will complicate a few things but this doesn't > > > look like a blocker on our end, just a change to how we track bits in a > > > shared bit/bytemap. > > > > > > > Hi Gregory, > > Thanks for reviewing the patches so quickly. > > > > No pressure, but look forward to your MHD work. :) > > > > Fan > > Starting to get into versioniong hell a bit, since the Niagara work was > based off of jonathan's branch and the mhd-dcd work needs some of the > extentions from that branch - while this branch is based on master. > > Probably we'll need to wait for a new cxl dated branch to try and sus > out the pain points before we push an RFC. I would not want to have > conflicting commits for something like this for example: > > https://lore.kernel.org/qemu-devel/20230901012914.226527-2-gregory.price@memverge.com/ > > We get merge conflicts here because this is behind that patch. So > pushing up an RFC in this state would be mostly useless to everyone Subtle hint noted ;) I'll build a fresh tree - any remaining rebases until QEMU 9.0 should be straight forward anyway. My ideal is that the NUMA GP series lands early in 9.1 cycle and this can go in parallel. I'd really like to get this in early if possible so we can start clearing some of the other stuff that ended up built on top of it! Jonathan > > ~Gregory
On Mon, Apr 22, 2024 at 01:04:48PM +0100, Jonathan Cameron wrote: > On Sat, 20 Apr 2024 16:35:46 -0400 > Gregory Price <gregory.price@memverge.com> wrote: > > > On Fri, Apr 19, 2024 at 11:43:14AM -0700, fan wrote: > > > On Fri, Apr 19, 2024 at 02:24:36PM -0400, Gregory Price wrote: > > > > > > > > added review to all patches, will hopefully be able to add a Tested-by > > > > tag early next week, along with a v1 RFC for MHD bit-tracking. > > > > > > > > We've been testing v5/v6 for a bit, so I expect as soon as we get the > > > > MHD code ported over to v7 i'll ship a tested-by tag pretty quick. > > > > > > > > The super-set release will complicate a few things but this doesn't > > > > look like a blocker on our end, just a change to how we track bits in a > > > > shared bit/bytemap. > > > > > > > > > > Hi Gregory, > > > Thanks for reviewing the patches so quickly. > > > > > > No pressure, but look forward to your MHD work. :) > > > > > > Fan > > > > Starting to get into versioniong hell a bit, since the Niagara work was > > based off of jonathan's branch and the mhd-dcd work needs some of the > > extentions from that branch - while this branch is based on master. > > > > Probably we'll need to wait for a new cxl dated branch to try and sus > > out the pain points before we push an RFC. I would not want to have > > conflicting commits for something like this for example: > > > > https://lore.kernel.org/qemu-devel/20230901012914.226527-2-gregory.price@memverge.com/ > > > > We get merge conflicts here because this is behind that patch. So > > pushing up an RFC in this state would be mostly useless to everyone > > Subtle hint noted ;) > Gentle nudge/poke/prod :P Got your updates, thank you! We should have something cleaned up today hopefully. > I'll build a fresh tree - any remaining rebases until QEMU 9.0 should be > straight forward anyway. My ideal is that the NUMA GP series lands early > in 9.1 cycle and this can go in parallel. I'd really like to > get this in early if possible so we can start clearing some of the other > stuff that ended up built on top of it! > > Jonathan > > > > > ~Gregory >
On Mon, 22 Apr 2024 13:04:48 +0100 Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > On Sat, 20 Apr 2024 16:35:46 -0400 > Gregory Price <gregory.price@memverge.com> wrote: > > > On Fri, Apr 19, 2024 at 11:43:14AM -0700, fan wrote: > > > On Fri, Apr 19, 2024 at 02:24:36PM -0400, Gregory Price wrote: > > > > > > > > added review to all patches, will hopefully be able to add a Tested-by > > > > tag early next week, along with a v1 RFC for MHD bit-tracking. > > > > > > > > We've been testing v5/v6 for a bit, so I expect as soon as we get the > > > > MHD code ported over to v7 i'll ship a tested-by tag pretty quick. > > > > > > > > The super-set release will complicate a few things but this doesn't > > > > look like a blocker on our end, just a change to how we track bits in a > > > > shared bit/bytemap. > > > > > > > > > > Hi Gregory, > > > Thanks for reviewing the patches so quickly. > > > > > > No pressure, but look forward to your MHD work. :) > > > > > > Fan > > > > Starting to get into versioniong hell a bit, since the Niagara work was > > based off of jonathan's branch and the mhd-dcd work needs some of the > > extentions from that branch - while this branch is based on master. > > > > Probably we'll need to wait for a new cxl dated branch to try and sus > > out the pain points before we push an RFC. I would not want to have > > conflicting commits for something like this for example: > > > > https://lore.kernel.org/qemu-devel/20230901012914.226527-2-gregory.price@memverge.com/ > > > > We get merge conflicts here because this is behind that patch. So > > pushing up an RFC in this state would be mostly useless to everyone > > Subtle hint noted ;) > > I'll build a fresh tree - any remaining rebases until QEMU 9.0 should be > straight forward anyway. My ideal is that the NUMA GP series lands early > in 9.1 cycle and this can go in parallel. I'd really like to > get this in early if possible so we can start clearing some of the other > stuff that ended up built on top of it! I've pushed to gitlab.com/jic23/qemu cxl-2024-04-22-draft Its extremely lightly tested so far. To save time, I've temporarily dropped the fm-api DCD initiate dynamic capacity add patch as that needs non trivial updates. I've not yet caught up with some other outstanding series, but I will almost certainly put them on top of DCD. Jonathan > > Jonathan > > > > > ~Gregory > >
On Mon, 22 Apr 2024 15:23:16 +0100 Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote: > On Mon, 22 Apr 2024 13:04:48 +0100 > Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > > > On Sat, 20 Apr 2024 16:35:46 -0400 > > Gregory Price <gregory.price@memverge.com> wrote: > > > > > On Fri, Apr 19, 2024 at 11:43:14AM -0700, fan wrote: > > > > On Fri, Apr 19, 2024 at 02:24:36PM -0400, Gregory Price wrote: > > > > > > > > > > added review to all patches, will hopefully be able to add a Tested-by > > > > > tag early next week, along with a v1 RFC for MHD bit-tracking. > > > > > > > > > > We've been testing v5/v6 for a bit, so I expect as soon as we get the > > > > > MHD code ported over to v7 i'll ship a tested-by tag pretty quick. > > > > > > > > > > The super-set release will complicate a few things but this doesn't > > > > > look like a blocker on our end, just a change to how we track bits in a > > > > > shared bit/bytemap. > > > > > > > > > > > > > Hi Gregory, > > > > Thanks for reviewing the patches so quickly. > > > > > > > > No pressure, but look forward to your MHD work. :) > > > > > > > > Fan > > > > > > Starting to get into versioniong hell a bit, since the Niagara work was > > > based off of jonathan's branch and the mhd-dcd work needs some of the > > > extentions from that branch - while this branch is based on master. > > > > > > Probably we'll need to wait for a new cxl dated branch to try and sus > > > out the pain points before we push an RFC. I would not want to have > > > conflicting commits for something like this for example: > > > > > > https://lore.kernel.org/qemu-devel/20230901012914.226527-2-gregory.price@memverge.com/ > > > > > > We get merge conflicts here because this is behind that patch. So > > > pushing up an RFC in this state would be mostly useless to everyone > > > > Subtle hint noted ;) > > > > I'll build a fresh tree - any remaining rebases until QEMU 9.0 should be > > straight forward anyway. My ideal is that the NUMA GP series lands early > > in 9.1 cycle and this can go in parallel. I'd really like to > > get this in early if possible so we can start clearing some of the other > > stuff that ended up built on top of it! > > I've pushed to gitlab.com/jic23/qemu cxl-2024-04-22-draft > Its extremely lightly tested so far. > > To save time, I've temporarily dropped the fm-api DCD initiate > dynamic capacity add patch as that needs non trivial updates. > > I've not yet caught up with some other outstanding series, but > I will almost certainly put them on top of DCD. If anyone pulled in meantime... I failed to push down a fix from my working tree on top of this. Goes to show I shouldn't ignore patches simply named "Push down" :( Updated on same branch. Jonathan > > Jonathan > > > > > Jonathan > > > > > > > > ~Gregory > > > > > >
© 2016 - 2024 Red Hat, Inc.