[26.04_linux-nvidia-bos] CXL: Refresh CXL Reset Series to v9 and rebase VFIO CXL series - #514
Draft
JiandiAnNVIDIA wants to merge 544 commits into
Draft
[26.04_linux-nvidia-bos] CXL: Refresh CXL Reset Series to v9 and rebase VFIO CXL series#514JiandiAnNVIDIA wants to merge 544 commits into
JiandiAnNVIDIA wants to merge 544 commits into
Conversation
BugLink: https://bugs.launchpad.net/bugs/2154527 arm64 provides helpers for changing a task's and a cpu's mpam partid/pmg values. These are used to back a number of resctrl_arch_ functions. Connect them up. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 9d2e1a9) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 Intel RDT's CDP feature allows the cache to use a different control value depending on whether the accesses was for instruction fetch or a data access. MPAM's equivalent feature is the other way up: the CPU assigns a different partid label to traffic depending on whether it was instruction fetch or a data access, which causes the cache to use a different control value based solely on the partid. MPAM can emulate CDP, with the side effect that the alternative partid is seen by all MSC, it can't be enabled per-MSC. Add the resctrl hooks to turn this on or off. Add the helpers that match a closid against a task, which need to be aware that the value written to hardware is not the same as the one resctrl is using. Update the 'arm64_mpam_global_default' variable the arch code uses during context switch to know when the per-cpu value should be used instead. Also, update these per-cpu values and sync the resulting mpam partid/pmg configuration to hardware. resctrl can enable CDP for L2 caches, L3 caches or both. When it is enabled by one and not the other MPAM globally enabled CDP but hides the effect on the other cache resource. This hiding is possible as CPOR is the only supported cache control and that uses a resource bitmap; two partids with the same bitmap act as one. Awkwardly, the MB controls don't implement CDP and CDP can't be hidden as the memory bandwidth control is a maximum per partid which can't be modelled with more partids. If the total maximum is used for both the data and instruction partids then then the maximum may be exceeded and if it is split in two then the one using more bandwidth will hit a lower limit. Hence, hide the MB controls completely if CDP is enabled for any resource. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Cc: Dave Martin <Dave.Martin@arm.com> Cc: Amit Singh Tomar <amitsinght@marvell.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 6789fb9) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 When CDP is not enabled, the 'rmid_entry's in the limbo list, rmid_busy_llc, map directly to a (PARTID,PMG) pair and when CDP is enabled the mapping is to two different pairs. As the limbo list is reused between mounts and CDP disabled on unmount this can lead to stale mapping and the limbo handler will then make monitor reads with potentially out of range PARTID. This may then cause an MPAM error interrupt and the driver will disable MPAM. No problems are expected if you just mount the resctrl file system once with CDP enabled and never unmount it. Hide CDP emulation behind CONFIG_EXPERT to protect the unwary. Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 01a0021) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 MPAM uses a fixed-point formats for some hardware controls. Resctrl provides the bandwidth controls as a percentage. Add helpers to convert between these. Ensure bwa_wd is at most 16 to make it clear higher values have no meaning. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 80d147d) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 Because MPAM's pmg aren't identical to RDT's rmid, resctrl handles some data structures by index. This allows x86 to map indexes to RMID, and MPAM to map them to partid-and-pmg. Add the helpers to do this. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Suggested-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 3e9b358) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 In order to calculate the rmid realloc threshold the size of the cache needs to be known. Cache domains will also be named after the cache id. So that this information can be extracted from cacheinfo we need to wait for it to be ready. The cacheinfo information is populated in device_initcall() so we wait for that. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 1c1e296) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 resctrl supports 'MB', as a percentage throttling of traffic from the L3. This is the control that mba_sc uses, so ideally the class chosen should be as close as possible to the counters used for mbm_total. If there is a single L3, it's the last cache, and the topology of the memory matches then the traffic at the memory controller will be equivalent to that at egress of the L3. If these conditions are met allow the memory class to back MB. MB's percentage control should be backed either with the fixed point fraction MBW_MAX or bandwidth portion bitmaps. The bandwidth portion bitmaps is not used as its tricky to pick which bits to use to avoid contention, and may be possible to expose this as something other than a percentage in the future. Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Dave Martin <Dave.Martin@arm.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 36528c7) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 resctrl specifies the format of the control schemes, and these don't match the hardware. Some of the conversions are a bit hairy - add some kunit tests. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Dave Martin <Dave.Martin@arm.com> [morse: squashed enough of Dave's fixes in here that it's his patch now!] Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 5dc8f73) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 Add the boilerplate that tells resctrl about the mpam monitors that are available. resctrl expects all (non-telemetry) monitors to be on the L3 and so advertise them there and invent an L3 resctrl resource if required. The L3 cache itself has to exist as the cache ids are used as the domain ids. Bring the resctrl monitor domains online and offline based on the cpus they contain. Support for specific monitor types is left to later. Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 264c285) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 resctrl exposes a counter via a file named llc_occupancy. This isn't really a counter as its value goes up and down, this is a snapshot of the cache storage usage monitor. Add some picking code which will only find an L3. The resctrl counter file is called llc_occupancy but we don't check it is the last one as it is already identified as L3. Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Dave Martin <dave.martin@arm.com> Signed-off-by: Dave Martin <dave.martin@arm.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 1458c4f) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 When resctrl wants to read a domain's 'QOS_L3_OCCUP', it needs to allocate a monitor on the corresponding resource. Monitors are allocated by class instead of component. Add helpers to allocate a CSU monitor. These helper return an out of range value for MBM counters. Allocating a montitor context is expected to block until hardware resources become available. This only makes sense for QOS_L3_OCCUP as unallocated MBM counters are losing data. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 2a3c79c) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 resctrl uses resctrl_arch_rmid_read() to read counters. CDP emulation means the counter may need reading in three different ways. The helpers behind the resctrl_arch_ functions will be re-used for the ABMC equivalent functions. Add the rounding helper for checking monitor values while we're here. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit fb56b29) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 resctrl's limbo code needs to be told when the data left in a cache is small enough for the partid+pmg value to be re-allocated. x86 uses the cache size divided by the number of rmid users the cache may have. Do the same, but for the smallest cache, and with the number of partid-and-pmg users. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 49b04e4) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 A few resctrl features and hooks need to be provided, but aren't needed or supported on MPAM platforms. resctrl has individual hooks to separately enable and disable the closid/partid and rmid/pmg context switching code. For MPAM this is all the same thing, as the value in struct task_struct is used to cache the value that should be written to hardware. arm64's context switching code is enabled once MPAM is usable, but doesn't touch the hardware unless the value has changed. For now event configuration is not supported, and can be turned off by returning 'false' from resctrl_arch_is_evt_configurable(). The new io_alloc feature is not supported either, always return false from the enable helper to indicate and fail the enable. Add this, and empty definitions for the other hooks. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit efc775e) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 One place in mixer.c still used a hard-coded number 16 instead of MAX_CHANNELS. Replace with it, so that we can extend the max number of channels gracefully. Link: https://lore.kernel.org/F1B104A5-CD6A-4A26-AB46-14BF233C0579@getmailspring.com Tested-by: Phil Willoughby <willerz@gmail.com> Link: https://patch.msgid.link/20260327153056.691575-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit ec9a788) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 Enough MPAM support is present to enable ARCH_HAS_CPU_RESCTRL. Let it rip^Wlink! ARCH_HAS_CPU_RESCTRL indicates resctrl can be enabled. It is enabled by the arch code simply because it has 'arch' in its name. This removes ARM_CPU_RESCTRL as a mimic of X86_CPU_RESCTRL. While here, move the ACPI dependency to the driver's Kconfig file. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 4aab135) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
…resctrl BugLink: https://bugs.launchpad.net/bugs/2154527 Now that MPAM links against resctrl, call resctrl_init() to register the filesystem and setup resctrl's structures. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit fb481ec) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 The MPAM specification includes the MPAMF_IIDR, which serves to uniquely identify the MSC implementation through a combination of implementer details, product ID, variant, and revision. Certain hardware issues/errata can be resolved using software workarounds. Introduce a quirk framework to allow workarounds to be enabled based on the MPAMF_IIDR value. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Co-developed-by: James Morse <james.morse@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit fa77452) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 The MPAM bandwidth partitioning controls will not be correctly configured, and hardware will retain default configuration register values, meaning generally that bandwidth will remain unprovisioned. To address the issue, follow the below steps after updating the MBW_MIN and/or MBW_MAX registers. - Perform 64b reads from all 12 bridge MPAM shadow registers at offsets (0x360048 + slice*0x10000 + partid*8). These registers are read-only. - Continue iterating until all 12 shadow register values match in a loop. pr_warn_once if the values fail to match within the loop count 1000. - Perform 64b writes with the value 0x0 to the two spare registers at offsets 0x1b0000 and 0x1c0000. In the hardware, writes to the MPAMCFG_MBW_MAX MPAMCFG_MBW_MIN registers are transformed into broadcast writes to the 12 shadow registers. The final two writes to the spare registers cause a final rank of downstream micro-architectural MPAM registers to be updated from the shadow copies. The intervening loop to read the 12 shadow registers helps avoid a race condition where writes to the spare registers occur before all shadow registers have been updated. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 70e81fb) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 In the T241 implementation of memory-bandwidth partitioning, in the absence of contention for bandwidth, the minimum bandwidth setting can affect the amount of achieved bandwidth. Specifically, the achieved bandwidth in the absence of contention can settle to any value between the values of MPAMCFG_MBW_MIN and MPAMCFG_MBW_MAX. Also, if MPAMCFG_MBW_MIN is set zero (below 0.78125%), once a core enters a throttled state, it will never leave that state. The first issue is not a concern if the MPAM software allows to program MPAMCFG_MBW_MIN through the sysfs interface. This patch ensures program MBW_MIN=1 (0.78125%) whenever MPAMCFG_MBW_MIN=0 is programmed. In the scenario where the resctrl doesn't support the MBW_MIN interface via sysfs, to achieve bandwidth closer to MBW_MAX in the absence of contention, software should configure a relatively narrow gap between MBW_MIN and MBW_MAX. The recommendation is to use a 5% gap to mitigate the problem. Clear the feature MBW_MIN feature from the class to ensure we don't accidentally change behaviour when resctrl adds support for a MBW_MIN interface. Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit a7efe23) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 The registers MSMON_MBWU_L and MSMON_MBWU return the number of requests rather than the number of bytes transferred. Bandwidth resource monitoring is performed at the last level cache, where each request arrive in 64Byte granularity. The current implementation returns the number of transactions received at the last level cache but does not provide the value in bytes. Scaling by 64 gives an accurate byte count to match the MPAM specification for the MSMON_MBWU and MSMON_MBWU_L registers. This patch fixes the issue by reporting the actual number of bytes instead of the number of transactions from __ris_msmon_read(). Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Peter Newman <peternewman@google.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit dc48eb1) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 CMN-650 is afflicted with an erratum where the CSU NRDY bit never clears. This tells us the monitor never finishes scanning the cache. The erratum document says to wait the maximum time, then ignore the field. Add a flag to indicate whether this is the final attempt to read the counter, and when this quirk is applied, ignore the NRDY field. This means accesses to this counter will always retry, even if the counter was previously programmed to the same values. The counter value is not expected to be stable, it drifts up and down with each allocation and eviction. The CSU register provides the value for a point in time. Tested-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Co-developed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit aeb8595) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 MPAM (Memory Partitioning and Monitoring) is now exposed to user-space via resctrl. Add some documentation so the user knows what features to expect. Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Jesse Chick <jessechick@os.amperecomputing.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 4ce0a2c) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 The last_cmd_status file is intended to report details about the most recent resctrl filesystem operation, specifically to aid in diagnosing failures. However, when parsing io_alloc_cbm, if a user provides a domain ID that does not exist in the resource, the operation fails with -EINVAL without updating last_cmd_status. This results in inconsistent behaviour where the system call returns an error, but last_cmd_status misleadingly reports "ok", leaving the user unaware that the failure was caused by an invalid domain ID. Write an error message to last_cmd_status when the target domain ID cannot be found. Fixes: 28fa2cc ("fs/resctrl: Introduce interface to modify io_alloc capacity bitmasks") Suggested-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://patch.msgid.link/20260325001159.447075-2-atomlin@atomlin.com (cherry picked from commit d06b8e7) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 Configuring the io_alloc_cbm interface requires an explicit domain ID for each cache domain. On systems with high core counts and numerous cache clusters, this requirement becomes cumbersome for automation and management tasks that aim to apply a uniform policy. Introduce a wildcard domain ID selector "*" for the io_alloc_cbm interface. This enables users to set the same Capacity Bitmask (CBM) across all cache domains in a single operation. Signed-off-by: Aaron Tomlin <atomlin@atomlin.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://patch.msgid.link/20260325001159.447075-3-atomlin@atomlin.com (cherry picked from commit d2bf45d) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 The x86 maintainers handle the resctrl filesystem and x86 architectural resctrl code. Even so, the x86 maintainers are not part of the resctrl section and not returned when scripts/get_maintainer.pl is run on resctrl filesystem code. With patches flowing via x86 maintainers resctrl should also ensure it follows the tip rules. Add the x86 maintainer alias, x86@kernel.org, to the resctrl section to ensure x86 maintainers are included in associated resctrl submissions. Add a reference to the tip tree handbook to make it clear which rules resctrl follows. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/4c14dd82e81737c6413e10fe097475b1cc0886fc.1775576382.git.reinette.chatre@intel.com (cherry picked from commit c611752) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 Using the stricter "./tools/docs/kernel-doc -Wall -v" to verify proper formatting of documentation comments includes warnings related to return markup on functions that are omitted during the default verification checks. This stricter verification reports a couple of missing return descriptions in resctrl: Warning: .../fs/resctrl/rdtgroup.c:1536 No description found for return value of 'rdtgroup_cbm_to_size' Warning: .../fs/resctrl/rdtgroup.c:3131 No description found for return value of 'mon_get_kn_priv' Warning: .../fs/resctrl/rdtgroup.c:3523 No description found for return value of 'cbm_ensure_valid' Warning: .../fs/resctrl/monitor.c:238 No description found for return value of 'resctrl_find_cleanest_closid' Add the missing return descriptions. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/1c50b9f7c73251c007133590986f127e1af57780.1775576382.git.reinette.chatre@intel.com (cherry picked from commit 7972701) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 The code to set MBA's alloc_capable to true appears to be trying to restore alloc_capable on unmount. This can never work because resctrl_arch_set_cdp_enabled() is never invoked with RDT_RESOURCE_MBA as the rid parameter. Consequently, mpam_resctrl_controls[RDT_RESOURCE_MBA].cdp_enabled always remains false. The alloc_capable setting in resctrl_arch_set_cdp_enabled() is to re-enable MBA if the caller opts in to separate control values using CDP for this resource. This doesn't happen today. Add a comment to describe this. However a bug remains where MBA allocation is permanently disabled after the mount with CDP option. Remounting without CDP cannot restore the MBA partition capability. Add a check to re-enable MBA when CDP is disabled, which happens on unmount. Fixes: 6789fb9 ("arm_mpam: resctrl: Add CDP emulation") Signed-off-by: Zeng Heng <zengheng4@huawei.com> [ morse: Added comment for existing code, added hunk to fix this bug from Ben H ] Reviewed-by: James Morse <james.morse@arm.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit f758340) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 Dan Carpenter reports that, in mpam_resctrl_alloc_domain(), any_mon_comp is used in an 'if' condition when it may be uninitialized. Initialize it to NULL so that the check behaves correctly when no monitor components are found. Reported-by: Dan Carpenter <error27@gmail.com> Fixes: 264c285 ("arm_mpam: resctrl: Add monitor initialisation and domain boilerplate") Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 67c0a48) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154527 resctrl_mon_ctx_waiters is not used outside of this file, so make it static. This fixes the sparse warning: drivers/resctrl/mpam_resctrl.c:25:1: warning: symbol 'resctrl_mon_ctx_waiters' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202603281842.c2K96tJA-lkp@intel.com/ Fixes: 2a3c79c ("arm_mpam: resctrl: Allow resctrl to allocate monitors") Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 4d5bbba) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
CXL bus reset can clear HDM global control and decoder programming. Restore cached HDM state after a successful cxl_bus reset while the IOMMU reset block remains active. This intentionally restores only the HDM component decoder state cached by the CXL reset support. It does not attempt to restore CXL Device DVSEC range/control registers. This was exercised with cxl_bus reset on a CXL Type 2 device. Testing confirmed that CXL Device DVSEC range/control state is a separate restore class from HDM component decoder state. This depends on the CXL reset series because it reuses the HDM state cache and restore helper introduced there. Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260709010304.680422-1-smadhavan@nvidia.com/) Signed-off-by: Jiandi An <jan@nvidia.com>
CXL cache writeback-invalidate can generate device-originated writes. Keep IOMMU translations available while CXL caching is disabled and WB+I completes, then prepare the IOMMU for reset before asserting CXL reset. This avoids ordering WB+I after pci_dev_reset_iommu_prepare(), where writeback traffic might fault if the IOMMU has already blocked new translations. Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260709010304.680422-1-smadhavan@nvidia.com/) Signed-off-by: Jiandi An <jan@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154302 Per CXL r3.1, sec 8.1.5.2, the Secondary Bus Reset (SBR) bit in the Bridge Control register of a CXL port has no effect unless the "Unmask SBR" bit in the Port Control Extensions Register is set. After b1956e2 ("PCI/CXL: Fail bus reset if upstream CXL Port has SBR masked"), Linux checks the "Unmask SBR" bit in pci_reset_bus_function(). But when probe==true, it previously returned 0, incorrectly indicating that SBR is a viable reset method for the device. As a result, "bus" is listed in the device's "reset_method" attribute even though the hardware is incapable of performing it. If a user writes "bus" to "reset_method" or triggers a reset that falls back to SBR, the operation fails with "write error: Inappropriate ioctl for device". If the link is operating in CXL mode (pcie_is_cxl()), return -ENOTTY immediately unless "Unmask SBR" is set, regardless of the probe argument. This ensures that "bus" is not advertised in "reset_methods" when the hardware prevents it, improving clarity for users and aligning the sysfs capability report with actual hardware behavior. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> [bhelgaas: commit log, use pcie_is_cxl()] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260225133801.30231-1-vidyas@nvidia.com (cherry picked from commit 702c1d5) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 cxl_probe_component_regs() finds the HDM decoder block during device probe and caches its location, but does not record the decoder count and does not expose the result outside drivers/cxl/. vfio-cxl needs the decoder count and the byte offset and size of the HDM block without re-running the probe sequence. Record decoder_cnt in rmap->count when parsing the HDM capability in cxl_probe_component_regs(), extend struct cxl_reg_map with a count member, and add cxl_get_hdm_info() to return offset, size, and count from the cached map. Export under the CXL namespace; stub to -EOPNOTSUPP when CONFIG_CXL_BUS is off. Co-developed-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit fd317b8 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [kobak: Added the target-local private drivers/cxl/cxl.h cxl_get_hdm_info() prototype because drivers/cxl/core/pci.c includes the private CXL header in addition to the public include/cxl/cxl.h declaration.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> [jan: dropped the private drivers/cxl/cxl.h cxl_get_hdm_info() prototype to match upstream v2 (public include/cxl/cxl.h only); drivers/cxl consumers resolve it via <cxl.h> -> <cxl/cxl.h>.]
…ader BugLink: https://bugs.launchpad.net/bugs/2152222 vfio-cxl lives outside drivers/cxl/ but still needs to locate the component register block and fill cxl_component_reg_map. BOS already has cxl_find_regblock() in include/cxl/pci.h, but cxl_probe_component_regs() was still private to drivers/cxl/cxl.h. Declare cxl_probe_component_regs() in include/cxl/pci.h next to the existing register-block helpers so VFIO CXL can use the parsed component register map. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit e02c1b7 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Move cxl_probe_component_regs() to include/cxl/pci.h instead of include/cxl/cxl.h to align with existing Srirangan/Alejandro convention; skip cxl_find_regblock() move as it is already in include/cxl/pci.h; add struct cxl_component_reg_map forward declaration] [kobak: Kept the target's private drivers/cxl/cxl.h declarations while adding the public include/cxl/pci.h header expected by VFIO CXL.] Signed-off-by: Koba Ko <kobak@nvidia.com> [jan: v9 rebase — declare cxl_find_regblock + cxl_probe_component_regs in include/cxl/cxl.h (CONFIG_CXL_BUS + stubs, enum cxl_regloc_type fwd decl) and drop the duplicate prototypes from drivers/cxl/cxl.h, matching Manish's upstream v2. Placed in cxl.h (not the original port's pci.h) per Alejandro v26/Srirangan v9 convention after the pci.h placement was reverted; drivers/cxl consumers still see the decls via drivers/cxl/cxl.h's #include <cxl/cxl.h>.] Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
…xl/cxl_regs.h BugLink: https://bugs.launchpad.net/bugs/2152222 VFIO and other code outside the CXL core needs the same offset/mask constants the core uses for the component register block and HDM decoders. Pull them into a new include/uapi/cxl/cxl_regs.h (GPL-2.0 WITH Linux-syscall-note) and include it from include/cxl/cxl.h. Use uapi-friendly __GENMASK helpers for masks and _BITUL() for single-bit flags because UAPI headers cannot depend on kernel-internal BIT(). Section comments in the new file reference CXL spec r4.0 numbering. For UAPI change, replaced the SZ_64K with actual size as the macro will not be available for userspace programs. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 52ead24 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Remove defines from include/cxl/cxl.h instead of drivers/cxl/cxl.h as they were already moved there by Srirangan's SAUCE commit, Add #include <asm/bitsperlong.h> needed by __GENMASK() in uapi header] Signed-off-by: Koba Ko <kobak@nvidia.com> [jan: keep Srirangan cxl-reset v9's cxl_hdm_info/cxl_commit/CONFIG_CXL_HDM block in include/cxl/cxl.h and dropped the moved register defines from the PRIVATE drivers/cxl/cxl.h (they were reverted out of public cxl.h on this branch, unlike the original port); the new uapi/cxl/cxl_regs.h now provides them to drivers/cxl via <cxl/cxl.h>. CXL_DECODER_MIN_GRANULARITY/MAX_ENCODED_IG and cxl_hdm_decoder_count stay private (used only in drivers/cxl, no vfio need).] Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
…dy wait BugLink: https://bugs.launchpad.net/bugs/2152222 Before accessing CXL device memory after reset/power-on, the driver must ensure media is ready. Not every CXL device implements the CXL Memory Device register group (many Type-2 devices do not). cxl_await_media_ready() reads cxlds->regs.memdev. Access to the memory device registers on a Type-2 device may result in kernel panic. Split the HDM DVSEC range-active poll out of cxl_await_media_ready() into a new function, cxl_await_range_active(). Type-2 devices often lack the CXLMDEV status register, so they need the range check without the memdev read. cxl_await_media_ready() now calls cxl_await_range_active() for the DVSEC poll, then reads the memory device status as before. Co-developed-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 023bae3 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Add cxl_await_range_active() declaration to include/cxl/pci.h unconditionally instead of include/cxl/cxl.h with CONFIG_CXL_BUS guards, consistent with existing convention] [kobak: Folded the private drivers/cxl/cxl.h cxl_await_range_active() prototype into this helper commit because drivers/cxl/core/pci.c includes the private CXL header.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> [jan: v9 rebase — moved cxl_await_range_active decl to include/cxl/cxl.h (CONFIG_CXL_BUS + stub), left pci.h minimal, and dropped the private drivers/cxl/cxl.h copy, matching upstream v2. Definition/export in pci.c unchanged.]
BugLink: https://bugs.launchpad.net/bugs/2152222 The Register Locator DVSEC (CXL 4.0 8.1.9) describes register blocks by BAR index (BIR) and offset within the BAR. CXL core currently only stores the resolved HPA (resource + offset) in struct cxl_register_map, so callers that need to use pci_iomap() or report the BAR to userspace must reverse-engineer the BAR from the HPA. Add bar_index and bar_offset to struct cxl_register_map and fill them in cxl_decode_regblock() when the regblock is BAR-backed (BIR 0-5). Add cxl_regblock_get_bar_info() so callers (e.g. vfio-cxl) can get BAR index and offset directly and use pci_iomap() instead of ioremap(HPA). Return -EINVAL if the map is not BAR-backed. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 947749b from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Add cxl_regblock_get_bar_info() declaration to include/cxl/pci.h unconditionally instead of include/cxl/cxl.h with CONFIG_CXL_BUS guards, consistent with existing convention, Add BIR range validation (reject BIR >= PCI_STD_NUM_BARS) plus a bar_index bounds check in cxl_regblock_get_bar_info()] [kobak: Added the target-local private drivers/cxl/cxl.h cxl_regblock_get_bar_info() prototype; struct cxl_register_map carries bar_index/bar_offset in include/cxl/cxl.h.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> [jan: v9 rebase — declare cxl_regblock_get_bar_info in include/cxl/cxl.h under CONFIG_CXL_BUS (+ !CONFIG stub returning -EINVAL) instead of the original port's include/cxl/pci.h; kept pci.h minimal and did not add a private drivers/cxl/cxl.h copy, matching upstream v2. The BIR-bounds/bar_index validation fixes are in regs.c (auto-merged).]
BugLink: https://bugs.launchpad.net/bugs/2152222 Vendor GPUs and accelerators can expose CXL.mem (HDM-D or HDM-DB) without using PCI class code 0x0502. VMMs need a stable way to learn DPA sizing, firmware commit state, and where the extra VFIO regions live. Add VFIO_DEVICE_FLAGS_CXL (bit 9) and VFIO_DEVICE_INFO_CAP_CXL (cap ID 6). The capability struct carries: hdm_regs_bar_index PCI BAR containing the component register block hdm_regs_offset byte offset within that BAR to the CXL.mem area (comp_reg_offset + CXL_CM_OFFSET) dpa_region_index VFIO region index for the DPA window comp_regs_region_index VFIO region index for the emulated COMP_REGS HDM decoder count and the HDM block offset within COMP_REGS are intentionally absent; both are derivable from the CXL Capability Array at COMP_REGS offset 0. Locate cap ID 0x5 (HDM) and read bits[31:20] of its entry for the byte offset. Then read bits[3:0] of the HDM Decoder Capability register for the count: count = (field == 0) ? 1 : field * 2. Two flags accompany the capability: VFIO_CXL_CAP_FIRMWARE_COMMITTED A decoder covering @dpa_size bytes was programmed and committed by platform firmware before device open. The VMM can use the DPA region immediately without re-committing. VFIO_CXL_CAP_CACHE_CAPABLE The device is HDM-DB (CXL.mem + CXL.cache). HDM-DB requires a Write-Back Invalidation sequence before FLR to flush dirty cache lines; HDM-D (CXL.mem only) does not. QEMU uses this flag to schedule WBI and to report Back-Invalidation capability accurately in the virtual CXL topology. Mirrors the Cache_Capable bit from the CXL DVSEC Capability register. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (cherry-picked from commit c0f4d24 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 Add struct vfio_pci_cxl_state and hang a pointer to it off vfio_pci_core_device. vdev->cxl stays NULL for non-CXL devices, so existing vfio-pci-core paths just pay a NULL check. The new struct embeds struct cxl_dev_state by value (CXL core uses container_of() against this field) and stores pointers to the cxl_memdev, root decoder, and endpoint decoder that the CXL core owns. cxl_region is not introduced here; it is added later when region management lands. The series builds the CXL Type-2 passthrough path inside vfio-pci-core rather than in a separate variant driver. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 87b80cc from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Resolve context mismatch in vfio_pci_core.h; add #include <cxl/pci.h> to vfio_cxl_priv.h for cxl_find_regblock/cxl_probe_component_regs declarations] [kobak: Preserved existing VFIO PCI DMABUF forward declarations while adding the CXL state forward declaration.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 Introduce the Kconfig option CONFIG_VFIO_CXL_CORE and the necessary build rules to compile CXL.mem passthrough infrastructure for vendor-specific CXL devices into the vfio-pci-core module. The new option depends on VFIO_PCI_CORE, CXL_BUS and CXL_MEM. Wire up the detection and cleanup entry-point stubs in vfio_pci_core_register_device() and vfio_pci_core_unregister_device() so that subsequent patches can fill in the CXL-specific logic without touching the vfio-pci-core flow again. The vfio_cxl_core.c file added here is an empty skeleton; the actual CXL detection and initialisation code is introduced in the following patch to keep this build-system patch reviewable on its own. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 336a144 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Resolve context mismatches in Kconfig, Makefile, and vfio_pci_priv.h due to missing upstream xe/dmabuf support in NV-Kernels base] [kobak: Preserved existing VFIO PCI DMABUF declarations while adding VFIO CXL stubs.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 Detect a vendor-specific CXL device at vfio-pci bind time and probe its HDM decoder register block. vfio_cxl_create_device_state() allocates per-device state via devm, reads the DVSEC length from PCI_DVSEC_HEADER1, and records MEM_CAPABLE and CACHE_CAPABLE from the CXL DVSEC. vfio_cxl_setup_regs() locates the component register block, claims and maps that BAR window, calls cxl_probe_component_regs() to find the HDM block, then unmaps and releases the window on all paths. vfio_pci_cxl_detect_and_init() enables PCI memory decoding for the probe, chains these setup steps, disables the device again, and leaves vdev->cxl NULL on failure so the device falls back to plain vfio-pci. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (cherry-picked from commit 939ebb7 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Use pci_get_dsn() instead of pdev->dev.id for cxlds serial; expand comment explaining why] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 Promote vfio_raw_config_write() and vfio_raw_config_read() to non-static so that the CXL DVSEC write handler in the next patch can call them. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (cherry-picked from commit 07d7141 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
… framework BugLink: https://bugs.launchpad.net/bugs/2152222 Add HDM decoder register emulation for CXL devices assigned to a guest. New file vfio_cxl_emu.c allocates comp_reg_virt[] covering the full component register block (CXL_COMPONENT_REG_BLOCK_SIZE), snapshots it from MMIO after probe, and registers a VFIO device region (VFIO_REGION_SUBTYPE_CXL_COMP_REGS) with read/write ops but no mmap, so every access hits the emulated buffer and write dispatchers. vfio_cxl_setup_virt_regs() is called from the tail of vfio_cxl_setup_regs(); vfio_cxl_clean_virt_regs() runs on cleanup. HDM decoder register defines come from include/uapi/cxl/cxl_regs.h. Bits with no hardware equivalent stay in vfio_cxl_priv.h. hdm_decoder_n_ctrl_write() allows the guest to clear the LOCK bit. A firmware-committed decoder arrives with LOCK=1; the guest driver must clear it before reprogramming BASE and SIZE with the VM's GPA. Such a write clears the bit in the shadow while preserving all other fields. Co-developed-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 4ab4955 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Resolve Makefile context mismatch due to missing upstream dmabuf support in NV-Kernels base, Add CTRL LOCK enforcement in BASE_LO/SIZE_LO writes, BI bit masking for non-cache-capable devices, pass max_size to vfio_cxl_setup_virt_regs() for bounds check, add vfio_pci_cxl_cleanup() in registration error path] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 After HDM registers are mapped, call cxl_await_range_active() so we only proceed when DVSEC ranges report active, avoiding access to the memdev register group that Type-2 devices may lack. This wait is required before re-snapshotting component registers: firmware commits final HDM decoder values such as SIZE_HIGH only after MEM_ACTIVE. Once cxl_await_range_active() confirms that state, re-read component regs with vfio_cxl_reinit_comp_regs() so those committed values land in comp_reg_virt. Read committed decoder size from hardware, set capacity via cxl_set_capacity(), and devm_cxl_add_memdev(). Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (cherry-picked from commit 537d8a2 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Line offset adjustments only (cascading from 0011 changes)] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 Region Management makes use of APIs provided by CXL_CORE as below: CREATE_REGION flow: 1. Validate request (size, decoder availability) 2. Allocate HPA via cxl_get_hpa_freespace() 3. Allocate DPA via cxl_request_dpa() 4. Create region via cxl_create_region() - commits HDM decoder 5. Get HPA range via cxl_get_region_range() DESTROY_REGION flow: 1. Detach decoder via cxl_decoder_detach() 2. Free DPA via cxl_dpa_free() 3. Release root decoder via cxl_put_root_decoder() Use DEFINE_FREE scope helpers so error paths unwind cleanly. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 799c46d from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Add borrowed-reference comment for precommitted decoders, init region to NULL, do not unregister precommitted regions in teardown] [kobak: Restored BOS CXL helper providers/exports and vfio-pci-core CXL namespace import so the region-management backport builds against BOS CXL core.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> [jan: v9 rebase — kept the new find_committed_endpoint_decoder()/cxl_get_committed_decoder() exports in hdm.c; dropped the cxld_set_interleave()/cxld_set_type() context hunk (v9's reusable-helper refactor already moved those to drivers/cxl/core/reset.c). Region-mgmt fixes in region.c/vfio_cxl_core.c auto-merged.]
…nd reset zap BugLink: https://bugs.launchpad.net/bugs/2152222 Wire the CXL DPA range up as a VFIO demand-paged region so QEMU can mmap guest device memory directly. Faults call vmf_insert_pfn() to insert one PFN at a time rather than mapping the full range upfront. CXL region lifecycle: - The CXL memory region is registered with VFIO layer during vfio_pci_open_device - mmap() establishes the VMA with vm_ops but inserts no PTEs - Each guest page fault calls vfio_cxl_region_page_fault() which inserts a single PFN under the memory_lock read side - On device reset, vfio_cxl_zap_region_locked() sets region_active=false and calls unmap_mapping_range() to invalidate all DPA PTEs atomically while holding memory_lock for writing - Faults racing with reset see region_active==false and return VM_FAULT_SIGBUS - vfio_cxl_reactivate_region() restores region_active after successful hardware reset Also integrate the zap/reactivate calls into vfio_pci_ioctl_reset() so that FLR correctly invalidates DPA mappings and restores them on success. Co-developed-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit f5e4191 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Resolve context mismatches in vfio_pci_core.c and vfio_pci_priv.h due to missing upstream dmabuf support in NV-Kernels base, Add vdev back-pointer in cxl_state, hold memory_lock read-side in fault/rw paths, advance *ppos in region rw, add vfio_direct_config_read export and use it instead of vfio_raw_config_read in DVSEC fallback] [kobak: Preserved existing VFIO PCI DMABUF reset movement while adding CXL DPA zap/reactivation.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 CXL devices expose DVSEC registers in PCI configuration space. Several of them affect device behavior (CXL.io/CXL.mem/CXL.cache enables, lock state, range bases) and must be virtualised so the guest cannot disturb host-owned policy. Add CXL-aware read and write handlers that operate on vdev->vconfig: - DVSEC reads come back from the vconfig shadow that vfio_config_init() already populates via vfio_ecap_init(). - DVSEC writes go through per-register handlers (cxl_dvsec_*_write) which apply the spec-defined reserved-bit and lock-bit masking before updating the shadow. - The handlers are wired in via vdev->dvsec_readfn / dvsec_writefn, which the global ecap_perms[PCI_EXT_CAP_ID_DVSEC] dispatcher routes to when the device is a CXL device. Non-CXL devices with a DVSEC capability fall through to direct hardware access. Signed-off-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 3ff6c19 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Resolve context mismatches in Makefile and vfio_pci_core.h due to missing upstream dmabuf/p2pdma forward declarations in NV-Kernels base, Carry Disable_Caching into Cache WBI hardware write, use vfio_direct_config_read fallback, add byte-aligned read/write routing for DVSEC registers, handle partial-byte W1C writes for STATUS/STATUS2, add PM_INIT_COMPLETION RW1CS handling] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 Register the DPA and component register region with VFIO layer. Region indices for both these regions are cached for quick lookup. vfio_cxl_register_cxl_region() - memremap(WB) the region HPA (treat CXL.mem as RAM, not MMIO) - Register VFIO_REGION_SUBTYPE_CXL - Records dpa_region_idx. vfio_cxl_register_comp_regs_region() - Registers VFIO_REGION_SUBTYPE_CXL_COMP_REGS with size hdm_reg_offset + hdm_reg_size - Records comp_reg_region_idx. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 6e2d9e5 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Check HDM COMMITTED bit before activating DPA region on precommitted decoders, add pm_runtime/memory-enabled gate in fault and rw paths, split vfio_cxl_zap_dpa() from prepare_reset(), add DPA zap in vfio_pci_zap_and_down_write_memory_lock(), add hot-reset CXL prepare/finish passes] [kobak: Withheld DPA mmap advertisement on BOS until CPU-readable backing for CXL DPA PFNMAP can be proven; DPA fd read/write remains advertised.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
…AR to userspace BugLink: https://bugs.launchpad.net/bugs/2152222 Expose CXL device capability through the VFIO device info ioctl and give userspace mmap access to the GPU/accelerator register windows in the component BAR while keeping the CXL component register block off-limits to user mappings. vfio_cxl_get_info() fills VFIO_DEVICE_INFO_CAP_CXL with the HDM register BAR index and byte offset, commit flags, and VFIO region indices for the DPA and COMP_REGS regions. HDM decoder count and the HDM block offset within COMP_REGS are not populated; both are derivable from the CXL Capability Array in the COMP_REGS region itself. vfio_cxl_get_region_info() handles VFIO_DEVICE_GET_REGION_INFO for the component register BAR. It builds a sparse-mmap capability that advertises only the GPU/accelerator register windows, carving out the CXL component register block. Three physical layouts are handled: Topology A comp block at BAR end: one area [0, comp_reg_offset) Topology B comp block at BAR start: one area [comp_end, bar_len) Topology C comp block in the middle: two areas, one on each side vfio_cxl_mmap_overlaps_comp_regs() checks whether an mmap request overlaps [comp_reg_offset, comp_reg_offset + comp_reg_size). vfio_pci_core_mmap() calls it to reject mmap of the component register block while allowing mmap of the GPU register windows in the sparse capability. This replaces the earlier blanket rejection of any mmap on the component BAR index. vfio_pci_bar_rw() applies the same overlap check, so fd pread()/pwrite() on the component BAR is also rejected when it would touch the component register subrange. All access to those registers goes through the dedicated COMP_REGS region, where the emulated HDM shadow lives. Hook both helpers into vfio_pci_ioctl_get_info() and vfio_pci_ioctl_get_region_info() in vfio_pci_core.c. The component BAR cannot be claimed exclusively since the CXL subsystem holds persistent sub-range iomem claims during HDM decoder setup. pci_request_selected_regions() returns EBUSY; pass bars=0 to skip the request and map directly via pci_iomap(). Physical ownership is assured by driver binding. Signed-off-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (cherry-picked from commit 9cd9248 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Add BAR bounds check for component block, handle full-BAR component reg case, add bar_mmap_supported gate, block BAR fd read/write and ioeventfd in component reg subrange] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 This commit provides an opt-out mechanism to disable the CXL support from vfio module. The opt-out is provided both build time and module load time. Build time option CONFIG_VFIO_CXL_CORE is used to enable/disable CXL support in vfio-pci module. For runtime disabling the CXL support, use the module parameter disable_cxl. The bare vfio-pci driver copies that parameter into the per-device core state before registration. Variant drivers own their probe policy and must set vdev->disable_cxl explicitly before registering the core device. Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 595c1ad from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Resolve context mismatch in vfio_pci.c probe function due to missing upstream pci_ops assignment in NV-Kernels base, Wrap disable_cxl field in #if IS_ENABLED(CONFIG_VFIO_CXL_CORE), update MODULE_PARM_DESC wording] [kobak: Preserved existing vfio-pci pci_ops assignment while wiring the CXL opt-out parameter.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
…ough BugLink: https://bugs.launchpad.net/bugs/2152222 Add Documentation/driver-api/vfio-pci-cxl.rst describing the architecture, VFIO interfaces, and operational constraints for CXL Type-2 (cache-coherent accelerator) passthrough via vfio-pci-core, and link it from the driver-api index. The document covers: - VFIO_DEVICE_FLAGS_CXL and VFIO_DEVICE_INFO_CAP_CXL: what the capability struct contains and what the FIRMWARE_COMMITTED and CACHE_CAPABLE flags mean - How to derive hdm_decoder_offset and hdm_count from the COMP_REGS region by traversing the CXL Capability Array to find cap ID 0x5 and reading the HDM Decoder Capability register - Topology-aware sparse mmap on the component BAR (topologies A, B, C covering comp block at end, start, or middle of the BAR) - Two extra VFIO device regions: COMP_REGS for the emulated HDM register state and the DPA memory window - DVSEC config write virtualization: what the guest sees vs. hardware - FLR coordination: DPA PTEs zapped before reset, restored after Signed-off-by: Manish Honap <mhonap@nvidia.com> Signed-off-by: Jiandi An <jan@nvidia.com> (backported from https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/) (backported from commit 696f0b1 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [jan: Rename vfio_cxl_zap_region_locked to vfio_cxl_prepare_reset and vfio_cxl_reactivate_region to vfio_cxl_finish_reset in docs] [kobak: Document BOS DPA policy as READ|WRITE without MMAP while preserving fd read/write support.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2152222 Add vfio_cxl_type2_test and build it from the vfio selftest Makefile. The binary expects a PCI BDF (argv or VFIO_SELFTESTS_BDF) with the device already on vfio-pci and CONFIG_VFIO_CXL_CORE enabled. It exercises: - VFIO_DEVICE_GET_INFO, - GET_REGION_INFO, - VFIO_DEVICE_INFO_CAP_CXL capability list, - sparse component-BAR vs DPA/COMP_REG regions, - HDM decoder emulation (masks, commit, lock), - DVSEC-backed config where the driver exposes it. Large region read/write loops and FLR-heavy test cases are still pending; Need to revisit these in next version of patches. vfio_pci_device_setup() skips auto-mmap for BARs that carry sparse-mmap capabilities; those require the caller to mmap only the windows advertised by the capability. Signed-off-by: Manish Honap <mhonap@nvidia.com> (backported from https://lore.kernel.org/r/20260401143917.108413-21-mhonap@nvidia.com) [kobak: Treat DPA mmap as optional because BOS intentionally withholds VFIO_REGION_INFO_FLAG_MMAP for the DPA region.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
… passthrough BugLink: https://bugs.launchpad.net/bugs/2152222 Enable VFIO CXL core support on amd64 and arm64 to allow CXL Type-2 device passthrough via vfio-pci. Signed-off-by: Jiandi An <jan@nvidia.com> (backported from commit 74b6b99 from https://github.com/JiandiAnNVIDIA/NV-Kernels.git cxl-vfio_2026-04-23) [kobak: Applied the equivalent annotation to debian.master/config/annotations because the 7.0 HWE target does not carry debian.nvidia-6.17/config/annotations.] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> [jan: Refresh CXL core annotations — annotate CONFIG_CXL_HDM which is auto-selected by CXL_BUS, drop the stale CONFIG_PCI_CXL annotation]
BugLink: https://bugs.launchpad.net/bugs/2153819 cxlmd->endpoint starts as ERR_PTR(-ENXIO) until endpoint port registration links the memdev to a real cxl_port. Treat NULL and error pointers as "endpoint not linked" before dereferencing cxlmd->endpoint in CXL helper paths. The BOS region-management backport exposes these helpers before endpoint linkage. This backports commit aff4cce ("NVIDIA: VR: SAUCE: cxl: Guard unlinked memdev endpoints"). Its PCI hunk is omitted because BOS already guards cxl_reset_done(). Fixes: 29317f8 ("cxl/mem: Introduce cxl_memdev_attach for CXL-dependent operation") Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
JiandiAnNVIDIA
marked this pull request as draft
July 29, 2026 06:08
Collaborator
Boro watcher review skippedThe PR watcher skips automatic boro reviews for changes with more than 50 commits. This change currently has 100 commits. To run the review anyway, ask Head: This comment is maintained by nv-pr-bot. It is updated when the watcher sees a newer head. |
Contributor
PR Validation ReportPatchscan
|
Collaborator
|
I realize this is still a draft, but my review with claude turned up some issues that I thought I'd share. I reviewed these and tried to eliminate anything that didn't look legitimate, but some I'm still not sure about. High1.
|
| Gate | Location | Consequence |
|---|---|---|
DPA zap in vfio_pci_zap_and_down_write_memory_lock() |
drivers/vfio/pci/vfio_pci_core.c:1652 |
vfio_pci_zap_bars() only covers BAR offsets; the DPA region lives in the device-region offset range, so user mappings of CXL.mem survive runtime-PM entry, D3 transitions and Memory-Space disable |
pm_runtime_engaged || !__vfio_pci_memory_enabled() in the fault handler |
drivers/vfio/pci/cxl/vfio_cxl_core.c:645 |
faults re-insert PFNs into a suspended / memory-disabled device |
same check in vfio_cxl_region_rw() |
drivers/vfio/pci/cxl/vfio_cxl_core.c:~815 |
same, for fd I/O |
prepare/finish passes in vfio_pci_dev_set_hot_reset() and in vfio_exp_config_write() / vfio_af_config_write() |
vfio_pci_core.c:2550, vfio_pci_config.c:912,997 |
after a bus reset or a guest-initiated FLR through PCIe Device Control, region_active stays true and comp_reg_virt[] is never re-read, so the guest keeps mapping DPA whose HDM decoders the reset just cleared |
Only vfio_pci_ioctl_reset() (vfio_pci_core.c:1250,1273) still handles this.
If dropping guest-driven INITIATE_CXL_RESET was the intent — vfio_cxl_config.c:100-104 now just warns "CXL reset requested but not yet supported" — these four items are separable from that change and worth keeping. vfio_cxl_comp_regs_rw() also lost its memory_lock read-side serialisation against comp_reg_virt[] rebuild
(drivers/vfio/pci/cxl/vfio_cxl_emu.c:283).
Medium
4. Sub-dword DVSEC writes corrupt the vconfig shadow
File: drivers/vfio/pci/cxl/vfio_cxl_config.c:205-232 (read), :292-312 (write)
Reachability: confirmed, unconditional. vfio_config_do_rw() (drivers/vfio/pci/vfio_pci_config.c:1943-1949) is the only sizing gate on the path and explicitly emits 1-byte chunks:
count = min(count, vfio_pci_cap_remaining_dword(vdev, *ppos));
if (count >= 4 && !(*ppos % 4)) count = 4;
else if (count >= 2 && !(*ppos % 2)) count = 2;
else count = 1;perm resolves to ecap_perms[PCI_EXT_CAP_ID_DVSEC] -> .writefn = vfio_pci_dvsec_dispatch_write (vfio_pci_config.c:1166) -> vdev->dvsec_writefn = vfio_cxl_dvsec_writefn, called with count == 1 and __le32 val = 0 holding only that byte. Nothing in between rejects sub-dword access.
Register offsets (include/uapi/cxl/cxl_regs.h:73-77): CONTROL 0x0c, STATUS 0x0e, CONTROL2 0x10, STATUS2 0x12, LOCK 0x14. PCI extended caps are dword-aligned, so 0x0c / 0x10 / 0x14 are dword-aligned and 0x0e / 0x12 are word- but not dword-aligned.
Failure scenarios, most severe first:
-
A guest polling
STATUS2.CACHE_INVALIDwith a 32-bit read can spin forever.vfio_cxl_dvsec_readfncase CXL_DVSEC_CONTROL2_OFFSETdoesmemcpy(val, vdev->vconfig + pos, count); withcount == 4that returns CONTROL2 and STATUS2 out of vconfig. Butcxl_dvsec_status2_write()never mirrors STATUS2 into vconfig — its own comment says "STATUS2 is not mirrored in vconfig - reads go to hardware" — and nothing updates it aftervfio_config_init()seeds it from hardware. Meanwhile CONTROL2 bit 1 (INITIATE_CACHE_WBI) is forwarded to hardware (vfio_cxl_config.c:135-141). So a guest that triggers WBI and then polls with a dword read at0x10reads the stale seed value indefinitely. A 16-bit poll at0x12works. The removedstatus2_hw_shadow_merge()existed exactly to handle the dword case. -
1-byte write at CONTROL (
0x0c) zeroes bits 15:8 of the shadow.wval16 = (u16)le32_to_cpu(val)= the single byte ->cxl_dvsec_control_write()->dvsec_virt_write16(CONTROL, new_val)writes all 16 bits. Lost bits: Cache_SF_Granularity (8:6), Cache_Clean_Eviction (9), P2P_Mem_Enable (12), Viral_Enable (14). Same shape for LOCK (0x14). -
Odd offsets are write-discarded but read from hardware.
dvsec_off0x0d/0x0f/0x11/0x13/0x15match no case in either switch: writes hitdefault:and are dropped, reads hitdefault:and go tovfio_raw_config_read(). So byte 1 of every virtualised register reads from hardware while byte 0 reads from shadow. Consequence:VIRAL_STATUS(STATUS bit 14, high byte) can never be cleared by any byte-granular write. -
4-byte write at
0x0cor0x10silently drops the STATUS / STATUS2 half. The reverted code forwarded it (cxl_dvsec_status_write(vdev, val >> 16)). A read of the same dword returns both halves, so read and write are asymmetric.
Severity bound — does not reach hardware. Every pci_write_config_word() in these handlers is gated on a low-byte bit: INITIATE_CACHE_WBI (bit 1) and DISABLE_CACHING (bit 0) in cxl_dvsec_control2_write(), VOLATILE_HDM_PRES_ERROR (bit 3) in cxl_dvsec_status2_write(). A 1-byte write carries those intact, so truncation cannot inject a wrong value into the device. cxl_dvsec_control_write() / _status_write() / _lock_write() only call dvsec_virt_write16(), which touches vdev->vconfig alone. This is guest-visible emulation incorrectness, not host or device state corruption — which is why this is Medium and finding 2 is not.
The reverted version handled all of this with reg_start = dvsec_off & ~1u, per-register shadow merging, and dword-spanning forwarding. Nothing replaced it.
5. Non-ARI Non-CXL Function Map bit index looks wrong
File: drivers/cxl/core/reset.c:772-782
static int cxl_reset_func_map_bit(struct pci_dev *sibling, bool ari)
{
if (ari)
return sibling->devfn;
/*
* Without ARI, the Function Map is organized as 32 device slots per
* conventional 3-bit function number.
*/
return PCI_FUNC(sibling->devfn) * 32 + PCI_SLOT(sibling->devfn);
}CXL r3.x section 8.1.4 defines the Non-CXL Function Map as one bit per Function of the device hosting the DVSEC (register 0 covers functions 0-31, register 1 functions 32-63, ...). The non-ARI index should be PCI_FUNC(devfn).
PCIe endpoints are always device 0, so the expression evaluates to PCI_FUNC * 32: function 1 tests bit 32 instead of bit 1.
Consequence: fails safe — a sibling the device declared non-CXL is treated as CXL, so cxl_reset_validate_function_scoped() returns -ENOTTY and the method is never advertised on multi-function devices. The feature is silently disabled where it should work.
Introduced by c2d27b26dd21, backported from https://lore.kernel.org/linux-cxl/20260709010304.680422-1-smadhavan@nvidia.com/, so it likely needs fixing upstream too.
6. Missing CPU cache invalidation downgraded to a warning
File: drivers/cxl/core/reset.c:1085-1089
if (!cpu_cache_has_invalidate_memregion()) {
pci_warn(pdev,
"CPU cache synchronization unavailable; continuing without cache invalidation\n");
return 0;
}The rest of the CXL core treats this as fatal (-ENXIO / -EPERM) precisely because stale dirty lines over an HPA range whose decoders are about to be torn down are a data-corruption hazard. cxl_hdm_ranges_request() claiming the ranges via request_mem_region() limits exposure, but this is a deliberate weakening of an upstream invariant — justify it in the commit message or return an error.
7. #ifdef CONFIG_CXL_BUS silently disables the feature at CXL_BUS=m
File: include/cxl/cxl.h:409
CXL_BUS is tristate. With CXL_BUS=m, CONFIG_CXL_BUS is undefined (CONFIG_CXL_BUS_MODULE is defined instead), so reset.c — built under CXL_HDM=y — picks up the stub:
static inline int
cxl_find_regblock(struct pci_dev *pdev, enum cxl_regloc_type type,
struct cxl_register_map *map)
{ return -EOPNOTSUPP; }__pci_cxl_hdm_init() then always fails, pdev->hdm is never populated and cxl_reset never works — with no build error and only a pci_dbg. This config ships CXL_BUS=y so it does not bite today. IS_ENABLED(CONFIG_CXL_BUS)` would make it robust.
8. probe and do-reset disagree for cxl_reset
File: drivers/cxl/core/reset.c:1338-1346
cxl_reset_context_init(&ctx, pdev);
if (probe)
return cxl_reset_validate_function_scoped(&ctx);
cxl_hdm_range_context_init(&range_ctx);
if (!cxl_reset_scope_hdm_available(&ctx)) {
rc = -ENOTTY;
goto out;
}The probe path never checks HDM availability, so reset_method advertises cxl_reset for devices where the actual reset always returns -ENOTTY. It falls through to the next method so nothing breaks, but the sysfs attribute lies, and the ABI doc (Documentation/ABI/testing/sysfs-bus-pci:156-166) only documents the scope condition.
Low / cleanup
All in drivers/cxl/core/reset.c unless noted.
__pci_cxl_hdm_init()dead code and error-path oddities:infois provably NULL after the guard at:401-405, soif (!info)(:425) is always true,allocated_infois always true, andinfo->decoder_count &&at:464is always false. Thegoto out_unmapat:495leavesrc == 0, so thepdev->hdmrace path freesinfoand returns success.PCI_COMMANDis restored twice on that path (:487then:515). The helpercxl_hdm_enable_mem()at:306does exactly what:411-423open-codes.cxl_pci_hdm_read_decoder():362-365:if (!committed) return 0; return 0;cxl_reset_wait_done():1259-1260computesdeadlinebefore the mandatory 100 ms RRS sleep. Withtimeout_ms == CXL_RESET_RRS_WAIT_MS(the two shortest spec encodings) the deadline has expired by the first poll, so the device gets exactly one status read.
Collaborator
|
@JiandiAnNVIDIA - I really appreciate the detailed PR summary, it really helped with understanding the logic behind this refresh. First, some comments / questions about provenance and patch trailers... I cannot explicitly tell where these patches came from but it looks like these were basically re-picked them from the existing branch. To make this clear, I think these patches should include a pick tag with the linux-nvidia-bos-7.0 SHA, then have annotation notes (if any for the v9 compat fixups) and then your SOB. That way the trailers would be ordered like this: Happy to discuss further over Slack or a call if further clarification is needed. Per the PR notes, this patch is an OOT fixup, which I assume means it has not been posted to LKML. However the commit message includes a LKML link to Srirangan’s reset series, is that intentional? While I don’t really have an issue with this, why are is this being reverted and then adding it back? Was it just to make the backporting cleaner? Now, for actual bug findings, my review with codex found a few overlaps with Seth’s review, so I’m not including those here. Of the items that Seth found but Codex missed, I had Codex check those findings to see if it agreed. The only one it did not agree with was Seth’s Medium 5 (Non-ARI Non-CXL Function Map bit index looks wrong) - here are the comments from Codex:
So that one will take a bit more investigation to determine if there is actually an issue or not. Lastly, my Codex review found two new items:
Source: re-picked VFIO CXL series, fd6a64c (vfio/cxl: Introduce HDM decoder register emulation framework) vfio_cxl_reinit_comp_regs() snapshots the hardware HDM decoder registers into comp_reg_virt[], then tries to sanitize firmware-committed decoders before exposing the shadow through the VFIO COMP_REGS region. The comment says committed decoder BASE must be zeroed so the host HPA is not exposed and QEMU can later program the guest GPA. However, the code only zeroes BASE_LOW/HIGH inside: So if hardware reports a decoder as COMMITTED but not LOCKed, the shadow still contains the host HPA copied from hardware. That violates the intended VFIO ABI and can disclose host physical address layout to userspace/the guest stack. The selftest also documents that BASE is expected to be zero for firmware-committed decoders. Suggested fix: for every COMMITTED decoder, always zero BASE_LOW/HIGH in comp_reg_virt[]; only make clearing COMMIT_LOCK conditional on LOCK being set.
Source: v9 CXL reset series. The return-code pattern comes from 1c05101 (cxl: Add CXL Device Reset helper) and becomes problematic once f7d2b74 adds HDM restore after reset. cxl_reset_execute() waits for reset completion, then re-enables CXL caching. If reset completed successfully but cxl_reset_enable_cache() fails, the helper overwrites rc with that late error: The caller only restores HDM decoders when cxl_reset_execute() returns success: That means a post-reset cache re-enable failure suppresses HDM restore even though the device reset already happened and volatile HDM decoder state may have been cleared. cxl_pci_target_reset_done() still runs afterward, so the system can unblock reset recovery with HDM state unrestored. Suggested fix: track “reset was initiated/completed” separately from the final return code. If reset completed, attempt HDM restore even when cache re-enable fails, then return/report the cache-enable error after preserving any restore failure ordering. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This branch refreshes the CXL reset support on
7.0-bosfrom the olderNV-SAUCE v1 save/restore + v5 cxl-reset stack to Srirangan's combined v9
"CXL Reset for Type-2 devices" series, and re-bases Manish's VFIO CXL
Type-2 passthrough v2 series on top of it.
Because the previous CXL/VFIO commits were already pushed, history is not
rewritten: the stale series is removed with
git revert, and the replacementseries is applied fresh on top. All re-applied NVIDIA SAUCE commits keep their
original
Signed-off-by/(backported from …)provenance, with[jan: …]notes documenting each v9 adaptation.
Motivation
that replaces the split v1 (save/restore) + v5 (cxl-reset) work and is aligned
to the upstream direction (
reset_method-based ABI, HDM decoder caching,BAR-relative HDM restore).
core helpers whose API changed under v9; it is re-based and adapted to the v9
conventions rather than the reverted v1/v5 layout.
include/cxl/cxl.h(Alejandro's convention, which Srirangan's v9 explicitlyfollows: "move shared decoder settings to include/cxl/cxl.h"), rather than
the
include/cxl/pci.hplacement used by the earlier port.What's in this PR (bottom → top)
Revert the stale NV-SAUCE CXL/ATS stack (reverts only — no history
rewrite): old VFIO CXL series + internal reset patches, v5 cxl-reset,
v1 CXL DVSEC save/restore, and the NV-SAUCE ATS "always on" series.
Re-apply the upstream ATS series (cherry-picked with
-x):PCI: Add pci_ats_required() for CXL.cache capable devicesPCI: Allow ATS to be always on for pre-CXL devicesiommu/arm-smmu-v3: Allow ATS to be always onThis restores the proper upstream owner of
PCI_DVSEC_CXL_CACHE_CAPABLEand
pci_ats_required(), which v9 depends on.Srirangan's v9 CXL Reset series (11 patches) + one out-of-tree fixup
(
cxl: Prepare IOMMU reset block after CXL cache WB+I).Backported from: https://lore.kernel.org/linux-cxl/20260709010304.680422-1-smadhavan@nvidia.com/
Retain
PCI/CXL: Hide SBR from reset_methods if masked by CXL(Vidya Sagar).Manish's VFIO CXL Type-2 v2 series (20 patches), adapted to v9.
Backported from: https://lore.kernel.org/linux-cxl/20260401143917.108413-1-mhonap@nvidia.com/
(v2 is used intentionally — v3 requires the not-yet-posted QEMU vfio-cxl v2.)
Key adaptations (v9 re-base)
include/cxl/cxl.h.cxl_find_regblock,cxl_probe_component_regs,cxl_await_range_active, andcxl_regblock_get_bar_infoare declared in the publicinclude/cxl/cxl.hunder
CONFIG_CXL_BUS(with!CONFIGstubs), matching upstream v2 and v9'sconvention, instead of the reverted
include/cxl/pci.hlayout.pci.hiskept minimal; redundant private
drivers/cxl/cxl.hprototypes were dropped(including a follow-up fix to patch 1's
cxl_get_hdm_info).include/uapi/cxl/cxl_regs.h. Component/HDM registerdefines are provided via the new uapi header; the duplicate copies were
removed from
drivers/cxl/cxl.hto avoid-Wmissing/redefinition breakage.cxld_set_interleave/cxld_set_typenow live indrivers/cxl/core/reset.c(v9's reusable-helpersplit); VFIO patch context that re-introduced the old
hdm.ccopies wasdropped to avoid unused-function build breaks.
manual), e.g. BIR range validation (
reject BIR >= PCI_STD_NUM_BARS) andbar_indexbounds checks incxl_regblock_get_bar_info().Provenance
Signed-off-bychains, and(backported from …)trailers.[jan: …]notes.Remaining work (follow-up, not yet in this branch)
(
/home/jan/patches/cxl-vfio-reset-internal/) — these target the removedv5 reset API (
cxl_dev_reset/cxl_do_reset) and must be rewired to v9'scxl_reset_function/cxl_reset_execute.CONFIG_VFIO_CXL_COREfor CXL Type-2 passthrough.cxl: Guard unlinked memdev endpoints(Nirmoy Das).