[PATCH -qemu] hw/cxl: Use host-only coherency for default CFMW restrictions

Davidlohr Bueso posted 1 patch 5 days, 22 hours ago
Failed in applying to current master (apply log)
docs/system/devices/cxl.rst | 5 +++--
hw/cxl/cxl-host.c           | 2 +-
qapi/machine.json           | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
[PATCH -qemu] hw/cxl: Use host-only coherency for default CFMW restrictions
Posted by Davidlohr Bueso 5 days, 22 hours ago
Change the default CXL Fixed Memory Window restrictions from
0x2f to 0xe, dropping Device Coherent and Back-Invalidate,
which are considered spec violations when using in combination
with host-only.

For HDM-D and HDM-DB models, the user will need to explicitly
pass the correct restrictions bitmask.

Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
---
 docs/system/devices/cxl.rst | 5 +++--
 hw/cxl/cxl-host.c           | 2 +-
 qapi/machine.json           | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/docs/system/devices/cxl.rst b/docs/system/devices/cxl.rst
index 32b1b5d7733b..079f65660dc3 100644
--- a/docs/system/devices/cxl.rst
+++ b/docs/system/devices/cxl.rst
@@ -385,7 +385,8 @@ An example of 4 devices below a switch suitable for 1, 2 or 4 way interleave::
   -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k
 
 An example of 4 type3 devices with volatile memory below a switch. Two of the devices
-use HDM-DB for coherence, which requires operating in Flit mode::
+use HDM-DB for coherence, which requires operating in Flit mode with the CXL Window
+configured with Back-Invalidate restrictions::
 
   qemu-system-x86_64 -M q35,cxl=on -m 4G,maxmem=8G,slots=8 -smp 4 \
   ...
@@ -405,7 +406,7 @@ use HDM-DB for coherence, which requires operating in Flit mode::
   -device cxl-type3,bus=swport2,volatile-memdev=cxl-mem2,id=cxl-mem2,sn=0x3 \
   -device cxl-downstream,port=3,bus=us0,id=swport3,chassis=0,slot=7 \
   -device cxl-type3,bus=swport3,volatile-memdev=cxl-mem3,id=cxl-mem3,sn=0x4 \
-  -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k
+  -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k,cxl-fmw.0.restrictions=0x2d
 
 A simple arm/virt example featuring a single direct connected CXL Type 3
 Volatile Memory device::
diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c
index 11a455b28ab8..a2595633ff0c 100644
--- a/hw/cxl/cxl-host.c
+++ b/hw/cxl/cxl-host.c
@@ -64,7 +64,7 @@ static void cxl_fixed_memory_window_config(CXLFixedMemoryWindowOptions *object,
     if (object->has_restrictions) {
         fw->restrictions = object->restrictions;
     } else {
-        fw->restrictions = 0x2f; /* No restrictions */
+        fw->restrictions = 0xe; /* host-only coherent, volatile, pmem */
     }
 
     fw->targets = g_malloc0_n(fw->num_targets, sizeof(*fw->targets));
diff --git a/qapi/machine.json b/qapi/machine.json
index 11ce0457d2f1..f832f0b84a53 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -558,7 +558,7 @@
 #     BIT(3) - Persistent
 #     BIT(4) - Fixed Device Config
 #     BIT(5) - BI
-#     Default is 0x2F
+#     Default is 0xE
 #
 # @targets: Target root bridge IDs from -device ...,id=<ID> for each
 #     root bridge.
-- 
2.39.5
Re: [PATCH -qemu] hw/cxl: Use host-only coherency for default CFMW restrictions
Posted by Jonathan Cameron 5 days, 12 hours ago
On Mon,  1 Jun 2026 21:30:29 -0700
Davidlohr Bueso <dave@stgolabs.net> wrote:

> Change the default CXL Fixed Memory Window restrictions from
> 0x2f to 0xe, dropping Device Coherent and Back-Invalidate,
> which are considered spec violations when using in combination
> with host-only.
> 
> For HDM-D and HDM-DB models, the user will need to explicitly
> pass the correct restrictions bitmask.
> 
> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>

So this only applies on my staging qemu tree (as the
restrictions control patch is not upstream yet). Would you mind
also doing a fix for mainline qemu as we need to change the default
prior to that restrictions patch?

For anyone wondering why that isn't upstream yet - it is mostly
a question of working out a better command line than writing the 
bitmap.  Probably as set of flags for each thing with checks
to ensure we don't end up with impossible combinations.

If you have time to look at that Davidlohr, would be much appreciated.
Without it the BI stuff in upstream qemu will be untestable.

Jonathan

> ---
>  docs/system/devices/cxl.rst | 5 +++--
>  hw/cxl/cxl-host.c           | 2 +-
>  qapi/machine.json           | 2 +-
>  3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/system/devices/cxl.rst b/docs/system/devices/cxl.rst
> index 32b1b5d7733b..079f65660dc3 100644
> --- a/docs/system/devices/cxl.rst
> +++ b/docs/system/devices/cxl.rst
> @@ -385,7 +385,8 @@ An example of 4 devices below a switch suitable for 1, 2 or 4 way interleave::
>    -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k
>  
>  An example of 4 type3 devices with volatile memory below a switch. Two of the devices
> -use HDM-DB for coherence, which requires operating in Flit mode::
> +use HDM-DB for coherence, which requires operating in Flit mode with the CXL Window
> +configured with Back-Invalidate restrictions::
>  
>    qemu-system-x86_64 -M q35,cxl=on -m 4G,maxmem=8G,slots=8 -smp 4 \
>    ...
> @@ -405,7 +406,7 @@ use HDM-DB for coherence, which requires operating in Flit mode::
>    -device cxl-type3,bus=swport2,volatile-memdev=cxl-mem2,id=cxl-mem2,sn=0x3 \
>    -device cxl-downstream,port=3,bus=us0,id=swport3,chassis=0,slot=7 \
>    -device cxl-type3,bus=swport3,volatile-memdev=cxl-mem3,id=cxl-mem3,sn=0x4 \
> -  -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k
> +  -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k,cxl-fmw.0.restrictions=0x2d
>  
>  A simple arm/virt example featuring a single direct connected CXL Type 3
>  Volatile Memory device::
> diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c
> index 11a455b28ab8..a2595633ff0c 100644
> --- a/hw/cxl/cxl-host.c
> +++ b/hw/cxl/cxl-host.c
> @@ -64,7 +64,7 @@ static void cxl_fixed_memory_window_config(CXLFixedMemoryWindowOptions *object,
>      if (object->has_restrictions) {
>          fw->restrictions = object->restrictions;
>      } else {
> -        fw->restrictions = 0x2f; /* No restrictions */
> +        fw->restrictions = 0xe; /* host-only coherent, volatile, pmem */
>      }
>  
>      fw->targets = g_malloc0_n(fw->num_targets, sizeof(*fw->targets));
> diff --git a/qapi/machine.json b/qapi/machine.json
> index 11ce0457d2f1..f832f0b84a53 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -558,7 +558,7 @@
>  #     BIT(3) - Persistent
>  #     BIT(4) - Fixed Device Config
>  #     BIT(5) - BI
> -#     Default is 0x2F
> +#     Default is 0xE
>  #
>  # @targets: Target root bridge IDs from -device ...,id=<ID> for each
>  #     root bridge.
Re: [PATCH -qemu] hw/cxl: Use host-only coherency for default CFMW restrictions
Posted by Davidlohr Bueso 5 days, 8 hours ago
On Tue, 02 Jun 2026, Jonathan Cameron wrote:

>On Mon,  1 Jun 2026 21:30:29 -0700
>Davidlohr Bueso <dave@stgolabs.net> wrote:
>
>> Change the default CXL Fixed Memory Window restrictions from
>> 0x2f to 0xe, dropping Device Coherent and Back-Invalidate,
>> which are considered spec violations when using in combination
>> with host-only.
>>
>> For HDM-D and HDM-DB models, the user will need to explicitly
>> pass the correct restrictions bitmask.
>>
>> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
>
>So this only applies on my staging qemu tree (as the
>restrictions control patch is not upstream yet). Would you mind
>also doing a fix for mainline qemu as we need to change the default
>prior to that restrictions patch?

Ah right, I keep forgetting that. I'm too used to using your tree
in my test scripts :)

>For anyone wondering why that isn't upstream yet - it is mostly
>a question of working out a better command line than writing the
>bitmap.  Probably as set of flags for each thing with checks
>to ensure we don't end up with impossible combinations.

I actually have no problem with just using restrictions, if the
user cares enough about not doing the default, then it should
not be hard to construct the bitmap.

>If you have time to look at that Davidlohr, would be much appreciated.
>Without it the BI stuff in upstream qemu will be untestable.

I had been thinking about an alternative, and went with one explicit
flag for each Window restriction - the problem with this is that
it gives users a lot of options to play with, so just passing partial
options requires qemu automatically setting flags - ie: just bi sets
device coherent; just passing volatile and/or pmem (no coherency) sets
host-only, etc.

I will send a combined patchset to (i) fix the current default
restrictions, and (ii) adds the new cfmw options.

Thanks,
Davidlohr
Re: [PATCH -qemu] hw/cxl: Use host-only coherency for default CFMW restrictions
Posted by Richard Cheng 5 days, 19 hours ago
On Mon, Jun 01, 2026 at 09:30:29PM +0800, Davidlohr Bueso wrote:
> Change the default CXL Fixed Memory Window restrictions from
> 0x2f to 0xe, dropping Device Coherent and Back-Invalidate,
> which are considered spec violations when using in combination
> with host-only.
> 
> For HDM-D and HDM-DB models, the user will need to explicitly
> pass the correct restrictions bitmask.
> 
> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
> ---
>  docs/system/devices/cxl.rst | 5 +++--
>  hw/cxl/cxl-host.c           | 2 +-
>  qapi/machine.json           | 2 +-
>  3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/system/devices/cxl.rst b/docs/system/devices/cxl.rst
> index 32b1b5d7733b..079f65660dc3 100644
> --- a/docs/system/devices/cxl.rst
> +++ b/docs/system/devices/cxl.rst
> @@ -385,7 +385,8 @@ An example of 4 devices below a switch suitable for 1, 2 or 4 way interleave::
>    -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k
>  
>  An example of 4 type3 devices with volatile memory below a switch. Two of the devices
> -use HDM-DB for coherence, which requires operating in Flit mode::
> +use HDM-DB for coherence, which requires operating in Flit mode with the CXL Window
> +configured with Back-Invalidate restrictions::
>  
>    qemu-system-x86_64 -M q35,cxl=on -m 4G,maxmem=8G,slots=8 -smp 4 \
>    ...
> @@ -405,7 +406,7 @@ use HDM-DB for coherence, which requires operating in Flit mode::
>    -device cxl-type3,bus=swport2,volatile-memdev=cxl-mem2,id=cxl-mem2,sn=0x3 \
>    -device cxl-downstream,port=3,bus=us0,id=swport3,chassis=0,slot=7 \
>    -device cxl-type3,bus=swport3,volatile-memdev=cxl-mem3,id=cxl-mem3,sn=0x4 \
> -  -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k
> +  -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k,cxl-fmw.0.restrictions=0x2d
> 

Hi Davidlohr,

Small question, how about states bit1, which is host-only can't be set explicitly in the example? the spec tells us host-only+BI is UB, so all of the devices in that window must be device-coherent. I would suggest a clearer doc so read won't assume they can do such thing.
 
>  A simple arm/virt example featuring a single direct connected CXL Type 3
>  Volatile Memory device::
> diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c
> index 11a455b28ab8..a2595633ff0c 100644
> --- a/hw/cxl/cxl-host.c
> +++ b/hw/cxl/cxl-host.c
> @@ -64,7 +64,7 @@ static void cxl_fixed_memory_window_config(CXLFixedMemoryWindowOptions *object,
>      if (object->has_restrictions) {
>          fw->restrictions = object->restrictions;
>      } else {
> -        fw->restrictions = 0x2f; /* No restrictions */
> +        fw->restrictions = 0xe; /* host-only coherent, volatile, pmem */
>      }
>  
>      fw->targets = g_malloc0_n(fw->num_targets, sizeof(*fw->targets));

LGTM.

> diff --git a/qapi/machine.json b/qapi/machine.json
> index 11ce0457d2f1..f832f0b84a53 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -558,7 +558,7 @@
>  #     BIT(3) - Persistent
>  #     BIT(4) - Fixed Device Config
>  #     BIT(5) - BI
> -#     Default is 0x2F
> +#     Default is 0xE
>  #
>  # @targets: Target root bridge IDs from -device ...,id=<ID> for each
>  #     root bridge.
> -- 
> 2.39.5
> 
>

Just one small tweak about commit message, you said Device coherent and BI are spec violations in cobination with host-only, but in fact the spec only calls out host-only + BI as UB.
For device coherent + host-only it says "more than one bit within this field may be set", for me dropping bit0 reads is more like default hygiene than a spec violation.
Maybe you would want to reword that part?

Best regards,
Richard Cheng.