Update the CFMW restrictions to also permit Back-Invalidate
flows by default, which is aligned with the no-restrictions
policy.

While at it, document the 'restrictions=' option.

Tested-by: Dongjoo Seo <dongjoo.seo1@samsung.com>
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
---
 hw/cxl/cxl-host.c | 2 +-
 qapi/machine.json | 3 ++-
 qemu-options.hx   | 4 +++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c
index e420b25176a6..ed0c76a31980 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 = 0xf; /* No restrictions */
+        fw->restrictions = 0x2f; /* No restrictions */
     }
 
     fw->targets = g_malloc0_n(fw->num_targets, sizeof(*fw->targets));
diff --git a/qapi/machine.json b/qapi/machine.json
index 225690d2986a..85e31432b038 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -555,7 +555,8 @@
 #     BIT(2) - Volatile
 #     BIT(3) - Persistent
 #     BIT(4) - Fixed Device Config
-#     Default is 0xF
+#     BIT(5) - BI
+#     Default is 0x2F
 #
 # @targets: Target root bridge IDs from -device ...,id=<ID> for each
 #     root bridge.
diff --git a/qemu-options.hx b/qemu-options.hx
index 075f4be2e3e6..0f27209aafa2 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -147,7 +147,7 @@ SRST
             -machine memory-backend=pc.ram
             -m 512M
 
-    ``cxl-fmw.0.targets.0=firsttarget,cxl-fmw.0.targets.1=secondtarget,cxl-fmw.0.size=size[,cxl-fmw.0.interleave-granularity=granularity]``
+    ``cxl-fmw.0.targets.0=firsttarget,cxl-fmw.0.targets.1=secondtarget,cxl-fmw.0.size=size[,cxl-fmw.0.interleave-granularity=granularity,restrictions=restrictions]``
         Define a CXL Fixed Memory Window (CFMW).
 
         Described in the CXL 2.0 ECN: CEDT CFMWS & QTG _DSM.
@@ -173,6 +173,8 @@ SRST
         interleave. Default 256 (bytes). Only 256, 512, 1k, 2k,
         4k, 8k and 16k granularities supported.
 
+        ``restrictions=restrictions`` bitmask with the restrictions of the CFMW.
+
         Example:
 
         ::
-- 
2.39.5

Davidlohr Bueso <dave@stgolabs.net> writes:

> Update the CFMW restrictions to also permit Back-Invalidate
> flows by default, which is aligned with the no-restrictions
> policy.
>
> While at it, document the 'restrictions=' option.

I'd split the patch.  Up to you.

> Tested-by: Dongjoo Seo <dongjoo.seo1@samsung.com>
> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
> ---
>  hw/cxl/cxl-host.c | 2 +-
>  qapi/machine.json | 3 ++-
>  qemu-options.hx   | 4 +++-
>  3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c
> index e420b25176a6..ed0c76a31980 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 = 0xf; /* No restrictions */
> +        fw->restrictions = 0x2f; /* No restrictions */
>      }
>  
>      fw->targets = g_malloc0_n(fw->num_targets, sizeof(*fw->targets));
> diff --git a/qapi/machine.json b/qapi/machine.json
> index 225690d2986a..85e31432b038 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -555,7 +555,8 @@
>  #     BIT(2) - Volatile
>  #     BIT(3) - Persistent
>  #     BIT(4) - Fixed Device Config
> -#     Default is 0xF
> +#     BIT(5) - BI
> +#     Default is 0x2F
>  #
>  # @targets: Target root bridge IDs from -device ...,id=<ID> for each
>  #     root bridge.

This changes the default of @restrictions.  No problem since
@restrictions has not been in any release.  If it was, we'd have to
consider backward compatibility.

[...]

On Thu, 18 Dec 2025 10:18:17 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Davidlohr Bueso <dave@stgolabs.net> writes:
> 
> > Update the CFMW restrictions to also permit Back-Invalidate
> > flows by default, which is aligned with the no-restrictions
> > policy.
> >
> > While at it, document the 'restrictions=' option.  
> 
> I'd split the patch.  Up to you.
Hi Markus,

As you note below the interface hasn't been in any release anyway and
is part of the long backlog I'm carrying and slowly getting
upstream. Bringing this in from the start with that restrictions
control should be fine.

However, backwards compatibility does need addressing
as this changes the default for things we do create today (with
no restrictions).

In this particular case, I don't think we care because there are no
BI capable devices before this series - so there can't be anything
using this feature for the host memory range it describes.

As such, the only result is the ACPI table says we have an extra
flag set which no one will care about.  Will need to update
the ACPI table tests though. I'll check.

Migration of CXL topologies is horribly broken currently anyway
so that's not a problem here. Given current usecases are strictly
software stack verification fixing that isn't a priority (yet).

Jonathan

> 
> > Tested-by: Dongjoo Seo <dongjoo.seo1@samsung.com>
> > Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
> > ---
> >  hw/cxl/cxl-host.c | 2 +-
> >  qapi/machine.json | 3 ++-
> >  qemu-options.hx   | 4 +++-
> >  3 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c
> > index e420b25176a6..ed0c76a31980 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 = 0xf; /* No restrictions */
> > +        fw->restrictions = 0x2f; /* No restrictions */
> >      }
> >  
> >      fw->targets = g_malloc0_n(fw->num_targets, sizeof(*fw->targets));
> > diff --git a/qapi/machine.json b/qapi/machine.json
> > index 225690d2986a..85e31432b038 100644
> > --- a/qapi/machine.json
> > +++ b/qapi/machine.json
> > @@ -555,7 +555,8 @@
> >  #     BIT(2) - Volatile
> >  #     BIT(3) - Persistent
> >  #     BIT(4) - Fixed Device Config
> > -#     Default is 0xF
> > +#     BIT(5) - BI
> > +#     Default is 0x2F
> >  #
> >  # @targets: Target root bridge IDs from -device ...,id=<ID> for each
> >  #     root bridge.  
> 
> This changes the default of @restrictions.  No problem since
> @restrictions has not been in any release.  If it was, we'd have to
> consider backward compatibility.
> 
> [...]
> 
>

Jonathan Cameron <jonathan.cameron@huawei.com> writes:

> On Thu, 18 Dec 2025 10:18:17 +0100
> Markus Armbruster <armbru@redhat.com> wrote:
>
>> Davidlohr Bueso <dave@stgolabs.net> writes:
>> 
>> > Update the CFMW restrictions to also permit Back-Invalidate
>> > flows by default, which is aligned with the no-restrictions
>> > policy.
>> >
>> > While at it, document the 'restrictions=' option.  
>> 
>> I'd split the patch.  Up to you.
> Hi Markus,
>
> As you note below the interface hasn't been in any release anyway and
> is part of the long backlog I'm carrying and slowly getting
> upstream. Bringing this in from the start with that restrictions
> control should be fine.
>
> However, backwards compatibility does need addressing
> as this changes the default for things we do create today (with
> no restrictions).
>
> In this particular case, I don't think we care because there are no
> BI capable devices before this series - so there can't be anything
> using this feature for the host memory range it describes.
>
> As such, the only result is the ACPI table says we have an extra
> flag set which no one will care about.  Will need to update
> the ACPI table tests though. I'll check.
>
> Migration of CXL topologies is horribly broken currently anyway
> so that's not a problem here. Given current usecases are strictly
> software stack verification fixing that isn't a priority (yet).

Good to know.  Work into commit message(s)?

On Thu, 18 Dec 2025 16:59:17 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Jonathan Cameron <jonathan.cameron@huawei.com> writes:
> 
> > On Thu, 18 Dec 2025 10:18:17 +0100
> > Markus Armbruster <armbru@redhat.com> wrote:
> >  
> >> Davidlohr Bueso <dave@stgolabs.net> writes:
> >>   
> >> > Update the CFMW restrictions to also permit Back-Invalidate
> >> > flows by default, which is aligned with the no-restrictions
> >> > policy.
> >> >
> >> > While at it, document the 'restrictions=' option.    
> >> 
> >> I'd split the patch.  Up to you.  
> > Hi Markus,
> >
> > As you note below the interface hasn't been in any release anyway and
> > is part of the long backlog I'm carrying and slowly getting
> > upstream. Bringing this in from the start with that restrictions
> > control should be fine.
> >
> > However, backwards compatibility does need addressing
> > as this changes the default for things we do create today (with
> > no restrictions).
> >
> > In this particular case, I don't think we care because there are no
> > BI capable devices before this series - so there can't be anything
> > using this feature for the host memory range it describes.
> >
> > As such, the only result is the ACPI table says we have an extra
> > flag set which no one will care about.  Will need to update
> > the ACPI table tests though. I'll check.
> >
> > Migration of CXL topologies is horribly broken currently anyway
> > so that's not a problem here. Given current usecases are strictly
> > software stack verification fixing that isn't a priority (yet).  
> 
> Good to know.  Work into commit message(s)?
> 
Will do.

I'll shuffle things around a bit whilst adding this to my staging
tree and first of all update the default (before the configuration
interface patch) to include this.  That patch will have some info
on backwards compatibility etc + ACPI tables updates (usual 3 patch
sequence to do that).

'll squash this patch into the generic restrictions configuration
interface patch.  That can then run separately wrt to
getting things upstreamed. It's a somewhat ugly interface at the
moment so that might needs some more involved discussion than
the BI support itself.

Jonathan