[PATCH 0/3] riscv: KVM: Expose Zicbom to the guest

[PATCH 0/3] riscv: KVM: Expose Zicbom to the guest

[Andrew Jones]

Add support for exposing the Zicbom extension to guests. This has been
tested over a QEMU including the Zicbom support [1] ([1] was rebased and
the Zicboz support from it was dropped.) QEMU was further modified to
ensure the cache block size was provided in the DT. kvmtool was also
modified [2] to test the new KVM API and provide the guest the cache
block size in its DT (The kvmtool patches are based on Anup's Svpbmt/Sstc
series [3]). These KVM patches are based on the riscv_init_cbom_blocksize()
cleanup patch from Palmer and the move and expose riscv_cbom_block_size
patch from Anup which were reposted [4]. This series is also available
here [5].

[1] https://gitlab.com/jones-drew/qemu/-/commits/riscv/zicbom
[2] https://github.com/jones-drew/kvmtool/commits/riscv/zicbom
[3] https://github.com/avpatel/kvmtool/commits/riscv_svpbmt_sstc_v1
[4] https://lore.kernel.org/linux-riscv/20220906074509.928865-1-ajones@ventanamicro.com/T/#u
[5] https://github.com/jones-drew/linux/commits/riscv/kvm/zicbom

Thanks,
drew

Andrew Jones (3):
  RISC-V: Output cbom-block-size
  RISC-V: KVM: Provide UAPI for Zicbom block size
  RISC-V: KVM: Expose Zicbom to the guest

 arch/riscv/include/uapi/asm/kvm.h |  2 ++
 arch/riscv/kvm/vcpu.c             | 11 +++++++++++
 arch/riscv/mm/cacheflush.c        |  5 ++++-
 3 files changed, 17 insertions(+), 1 deletion(-)

-- 
2.37.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 1/3] RISC-V: Output cbom-block-size

[Andrew Jones]

Provide an info message with the block size when the Zicbom extension is
present and the block size has been determined.

Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
---
 arch/riscv/mm/cacheflush.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
index e5b087be1577..8595baf8e403 100644
--- a/arch/riscv/mm/cacheflush.c
+++ b/arch/riscv/mm/cacheflush.c
@@ -122,7 +122,9 @@ void riscv_init_cbom_blocksize(void)
 		}
 	}
 
-	if (probed_block_size)
+	if (probed_block_size) {
 		riscv_cbom_block_size = probed_block_size;
+		pr_info("riscv: Zicbom: Cache blocksize is %u bytes", probed_block_size);
+	}
 }
 #endif
-- 
2.37.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 2/3] RISC-V: KVM: Provide UAPI for Zicbom block size

[Andrew Jones]

We're about to allow guests to use the Zicbom extension. KVM
userspace needs to know the cache block size in order to
properly advertise it to the guest. Provide a virtual config
register for userspace to get it with the GET_ONE_REG API, but
setting it cannot be supported, so disallow SET_ONE_REG.

Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
---
 arch/riscv/include/uapi/asm/kvm.h | 1 +
 arch/riscv/kvm/vcpu.c             | 6 ++++++
 arch/riscv/mm/cacheflush.c        | 1 +
 3 files changed, 8 insertions(+)

diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
index 7351417afd62..b9a4cf36be4b 100644
--- a/arch/riscv/include/uapi/asm/kvm.h
+++ b/arch/riscv/include/uapi/asm/kvm.h
@@ -48,6 +48,7 @@ struct kvm_sregs {
 /* CONFIG registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
 struct kvm_riscv_config {
 	unsigned long isa;
+	unsigned long zicbom_block_size;
 };
 
 /* CORE registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index d0f08d5b4282..3f36e79876e7 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -18,6 +18,7 @@
 #include <linux/fs.h>
 #include <linux/kvm_host.h>
 #include <asm/csr.h>
+#include <asm/cacheflush.h>
 #include <asm/hwcap.h>
 
 const struct _kvm_stats_desc kvm_vcpu_stats_desc[] = {
@@ -254,6 +255,9 @@ static int kvm_riscv_vcpu_get_reg_config(struct kvm_vcpu *vcpu,
 	case KVM_REG_RISCV_CONFIG_REG(isa):
 		reg_val = vcpu->arch.isa[0] & KVM_RISCV_BASE_ISA_MASK;
 		break;
+	case KVM_REG_RISCV_CONFIG_REG(zicbom_block_size):
+		reg_val = riscv_cbom_block_size;
+		break;
 	default:
 		return -EINVAL;
 	}
@@ -311,6 +315,8 @@ static int kvm_riscv_vcpu_set_reg_config(struct kvm_vcpu *vcpu,
 			return -EOPNOTSUPP;
 		}
 		break;
+	case KVM_REG_RISCV_CONFIG_REG(zicbom_block_size):
+		return -EOPNOTSUPP;
 	default:
 		return -EINVAL;
 	}
diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
index 8595baf8e403..c555ac7ae69c 100644
--- a/arch/riscv/mm/cacheflush.c
+++ b/arch/riscv/mm/cacheflush.c
@@ -90,6 +90,7 @@ void flush_icache_pte(pte_t pte)
 #endif /* CONFIG_MMU */
 
 unsigned int riscv_cbom_block_size;
+EXPORT_SYMBOL_GPL(riscv_cbom_block_size);
 
 #ifdef CONFIG_RISCV_ISA_ZICBOM
 void riscv_init_cbom_blocksize(void)
-- 
2.37.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 3/3] RISC-V: KVM: Expose Zicbom to the guest

[Andrew Jones]

Guests may use the cbo.inval,clean,flush instructions when the
CPU has the Zicbom extension and the hypervisor sets henvcfg.CBIE
(for cbo.inval) and henvcfg.CBCFE (for cbo.clean,flush).

Add Zicbom support for KVM guests which may be enabled and
disabled from KVM userspace using the ISA extension ONE_REG API.

Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
---
 arch/riscv/include/uapi/asm/kvm.h | 1 +
 arch/riscv/kvm/vcpu.c             | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
index b9a4cf36be4b..ed37a4a6e5cf 100644
--- a/arch/riscv/include/uapi/asm/kvm.h
+++ b/arch/riscv/include/uapi/asm/kvm.h
@@ -99,6 +99,7 @@ enum KVM_RISCV_ISA_EXT_ID {
 	KVM_RISCV_ISA_EXT_M,
 	KVM_RISCV_ISA_EXT_SVPBMT,
 	KVM_RISCV_ISA_EXT_SSTC,
+	KVM_RISCV_ISA_EXT_ZICBOM,
 	KVM_RISCV_ISA_EXT_MAX,
 };
 
diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index 3f36e79876e7..3ce4f1c11b4c 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -54,6 +54,7 @@ static const unsigned long kvm_isa_ext_arr[] = {
 	RISCV_ISA_EXT_m,
 	RISCV_ISA_EXT_SVPBMT,
 	RISCV_ISA_EXT_SSTC,
+	RISCV_ISA_EXT_ZICBOM,
 };
 
 static unsigned long kvm_riscv_vcpu_base2isa_ext(unsigned long base_ext)
@@ -795,6 +796,10 @@ static void kvm_riscv_vcpu_update_config(const unsigned long *isa)
 
 	if (__riscv_isa_extension_available(isa, RISCV_ISA_EXT_SSTC))
 		henvcfg |= ENVCFG_STCE;
+
+	if (__riscv_isa_extension_available(isa, RISCV_ISA_EXT_ZICBOM))
+		henvcfg |= (ENVCFG_CBIE | ENVCFG_CBCFE);
+
 	csr_write(CSR_HENVCFG, henvcfg);
 #ifdef CONFIG_32BIT
 	csr_write(CSR_HENVCFGH, henvcfg >> 32);
-- 
2.37.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] RISC-V: Output cbom-block-size

[Conor.Dooley]

On 06/09/2022 09:35, Andrew Jones wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Provide an info message with the block size when the Zicbom extension is
> present and the block size has been determined.

Why might someone care about this?

> 
> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> ---
>   arch/riscv/mm/cacheflush.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
> index e5b087be1577..8595baf8e403 100644
> --- a/arch/riscv/mm/cacheflush.c
> +++ b/arch/riscv/mm/cacheflush.c
> @@ -122,7 +122,9 @@ void riscv_init_cbom_blocksize(void)
>                  }
>          }
> 
> -       if (probed_block_size)
> +       if (probed_block_size) {
>                  riscv_cbom_block_size = probed_block_size;
> +               pr_info("riscv: Zicbom: Cache blocksize is %u bytes", probed_block_size);
> +       }
>   }
>   #endif
> --
> 2.37.2
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] RISC-V: Output cbom-block-size

[Andrew Jones]

On Tue, Sep 06, 2022 at 08:40:23AM +0000, Conor.Dooley@microchip.com wrote:
> On 06/09/2022 09:35, Andrew Jones wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > Provide an info message with the block size when the Zicbom extension is
> > present and the block size has been determined.
> 
> Why might someone care about this?

I was unaware of anywhere else besides hardware descriptions where this is
published. And, while dmesg isn't really publishing it in a way that is
useful to anything other than human readers either, it at least makes it
easy for a user to check it for sanity purposes (which is what I used it
for) or even for applying it if they want to write something that needs it
and the OS provides U-mode access to CMO.

I'm not married to the idea, though, so if people would rather have less
logs than this information, then I'm fine with dropping the patch.

Thanks,
drew

> 
> > 
> > Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> > ---
> >   arch/riscv/mm/cacheflush.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
> > index e5b087be1577..8595baf8e403 100644
> > --- a/arch/riscv/mm/cacheflush.c
> > +++ b/arch/riscv/mm/cacheflush.c
> > @@ -122,7 +122,9 @@ void riscv_init_cbom_blocksize(void)
> >                  }
> >          }
> > 
> > -       if (probed_block_size)
> > +       if (probed_block_size) {
> >                  riscv_cbom_block_size = probed_block_size;
> > +               pr_info("riscv: Zicbom: Cache blocksize is %u bytes", probed_block_size);
> > +       }
> >   }
> >   #endif
> > --
> > 2.37.2
> > 
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] RISC-V: Output cbom-block-size

[Conor.Dooley]

On 06/09/2022 09:55, Andrew Jones wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Tue, Sep 06, 2022 at 08:40:23AM +0000, Conor.Dooley@microchip.com wrote:
>> On 06/09/2022 09:35, Andrew Jones wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> Provide an info message with the block size when the Zicbom extension is
>>> present and the block size has been determined.
>>
>> Why might someone care about this?
> 
> I was unaware of anywhere else besides hardware descriptions where this is
> published. And, while dmesg isn't really publishing it in a way that is
> useful to anything other than human readers either, it at least makes it
> easy for a user to check it for sanity purposes (which is what I used it
> for) or even for applying it if they want to write something that needs it
> and the OS provides U-mode access to CMO.
> 
> I'm not married to the idea, though, so if people would rather have less
> logs than this information, then I'm fine with dropping the patch.

I don't really care either way about logging it, if it helps people to
be able to see it perhaps there's a better location than dmesg -
would {debug,sys}fs be overkill?

I was just more interested in the motivation behind the change itself.
Maybe some of the above in the commit message wuld be nice?

> 
> Thanks,
> drew
> 
>>
>>>
>>> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
>>> ---
>>>    arch/riscv/mm/cacheflush.c | 4 +++-
>>>    1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
>>> index e5b087be1577..8595baf8e403 100644
>>> --- a/arch/riscv/mm/cacheflush.c
>>> +++ b/arch/riscv/mm/cacheflush.c
>>> @@ -122,7 +122,9 @@ void riscv_init_cbom_blocksize(void)
>>>                   }
>>>           }
>>>
>>> -       if (probed_block_size)
>>> +       if (probed_block_size) {
>>>                   riscv_cbom_block_size = probed_block_size;
>>> +               pr_info("riscv: Zicbom: Cache blocksize is %u bytes", probed_block_size);
>>> +       }
>>>    }
>>>    #endif
>>> --
>>> 2.37.2
>>>
>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] RISC-V: Output cbom-block-size

[Andrew Jones]

On Tue, Sep 06, 2022 at 10:55:33AM +0200, Andrew Jones wrote:
> On Tue, Sep 06, 2022 at 08:40:23AM +0000, Conor.Dooley@microchip.com wrote:
> > On 06/09/2022 09:35, Andrew Jones wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > > 
> > > Provide an info message with the block size when the Zicbom extension is
> > > present and the block size has been determined.
> > 
> > Why might someone care about this?
> 
> I was unaware of anywhere else besides hardware descriptions where this is
> published. And, while dmesg isn't really publishing it in a way that is
> useful to anything other than human readers either, it at least makes it
> easy for a user to check it for sanity purposes (which is what I used it
> for) or even for applying it if they want to write something that needs it
> and the OS provides U-mode access to CMO.

Of course for applying it in U-mode programs it'd probably be better to
introduce a sysconf variable or similar to get it.

drew

> 
> I'm not married to the idea, though, so if people would rather have less
> logs than this information, then I'm fine with dropping the patch.
> 
> Thanks,
> drew
> 
> > 
> > > 
> > > Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> > > ---
> > >   arch/riscv/mm/cacheflush.c | 4 +++-
> > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
> > > index e5b087be1577..8595baf8e403 100644
> > > --- a/arch/riscv/mm/cacheflush.c
> > > +++ b/arch/riscv/mm/cacheflush.c
> > > @@ -122,7 +122,9 @@ void riscv_init_cbom_blocksize(void)
> > >                  }
> > >          }
> > > 
> > > -       if (probed_block_size)
> > > +       if (probed_block_size) {
> > >                  riscv_cbom_block_size = probed_block_size;
> > > +               pr_info("riscv: Zicbom: Cache blocksize is %u bytes", probed_block_size);
> > > +       }
> > >   }
> > >   #endif
> > > --
> > > 2.37.2
> > > 
> > 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] RISC-V: Output cbom-block-size

[Andrew Jones]

On Tue, Sep 06, 2022 at 09:00:20AM +0000, Conor.Dooley@microchip.com wrote:
> On 06/09/2022 09:55, Andrew Jones wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > On Tue, Sep 06, 2022 at 08:40:23AM +0000, Conor.Dooley@microchip.com wrote:
> >> On 06/09/2022 09:35, Andrew Jones wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> Provide an info message with the block size when the Zicbom extension is
> >>> present and the block size has been determined.
> >>
> >> Why might someone care about this?
> > 
> > I was unaware of anywhere else besides hardware descriptions where this is
> > published. And, while dmesg isn't really publishing it in a way that is
> > useful to anything other than human readers either, it at least makes it
> > easy for a user to check it for sanity purposes (which is what I used it
> > for) or even for applying it if they want to write something that needs it
> > and the OS provides U-mode access to CMO.
> > 
> > I'm not married to the idea, though, so if people would rather have less
> > logs than this information, then I'm fine with dropping the patch.
> 
> I don't really care either way about logging it, if it helps people to
> be able to see it perhaps there's a better location than dmesg -
> would {debug,sys}fs be overkill?

Thinking about this some more, I think sysfs would probably be the better
way to go from the start. This patch should probably be dropped and I
can try to add a sysfs node. The hard part of that will be the naming...
How about

 /sys/devices/system/cpu/cpu*/cache/cmo_block_size

Thanks,
drew

> 
> I was just more interested in the motivation behind the change itself.
> Maybe some of the above in the commit message wuld be nice?
> 
> > 
> > Thanks,
> > drew
> > 
> >>
> >>>
> >>> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> >>> ---
> >>>    arch/riscv/mm/cacheflush.c | 4 +++-
> >>>    1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
> >>> index e5b087be1577..8595baf8e403 100644
> >>> --- a/arch/riscv/mm/cacheflush.c
> >>> +++ b/arch/riscv/mm/cacheflush.c
> >>> @@ -122,7 +122,9 @@ void riscv_init_cbom_blocksize(void)
> >>>                   }
> >>>           }
> >>>
> >>> -       if (probed_block_size)
> >>> +       if (probed_block_size) {
> >>>                   riscv_cbom_block_size = probed_block_size;
> >>> +               pr_info("riscv: Zicbom: Cache blocksize is %u bytes", probed_block_size);
> >>> +       }
> >>>    }
> >>>    #endif
> >>> --
> >>> 2.37.2
> >>>
> >>
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] RISC-V: Output cbom-block-size

[Conor.Dooley]

On 06/09/2022 10:29, Andrew Jones wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Tue, Sep 06, 2022 at 09:00:20AM +0000, Conor.Dooley@microchip.com wrote:
>> On 06/09/2022 09:55, Andrew Jones wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On Tue, Sep 06, 2022 at 08:40:23AM +0000, Conor.Dooley@microchip.com wrote:
>>>> On 06/09/2022 09:35, Andrew Jones wrote:
>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>
>>>>> Provide an info message with the block size when the Zicbom extension is
>>>>> present and the block size has been determined.
>>>>
>>>> Why might someone care about this?
>>>
>>> I was unaware of anywhere else besides hardware descriptions where this is
>>> published. And, while dmesg isn't really publishing it in a way that is
>>> useful to anything other than human readers either, it at least makes it
>>> easy for a user to check it for sanity purposes (which is what I used it
>>> for) or even for applying it if they want to write something that needs it
>>> and the OS provides U-mode access to CMO.
>>>
>>> I'm not married to the idea, though, so if people would rather have less
>>> logs than this information, then I'm fine with dropping the patch.
>>
>> I don't really care either way about logging it, if it helps people to
>> be able to see it perhaps there's a better location than dmesg -
>> would {debug,sys}fs be overkill?
> 
> Thinking about this some more, I think sysfs would probably be the better
> way to go from the start. This patch should probably be dropped and I
> can try to add a sysfs node. The hard part of that will be the naming...
> How about
> 
>   /sys/devices/system/cpu/cpu*/cache/cmo_block_size

Seems sane to me, but I am oh-so-very-far from an expert here.
Heiko might have a more qualified opinion.

> 
> Thanks,
> drew
> 
>>
>> I was just more interested in the motivation behind the change itself.
>> Maybe some of the above in the commit message wuld be nice?
>>
>>>
>>> Thanks,
>>> drew
>>>
>>>>
>>>>>
>>>>> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
>>>>> ---
>>>>>     arch/riscv/mm/cacheflush.c | 4 +++-
>>>>>     1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
>>>>> index e5b087be1577..8595baf8e403 100644
>>>>> --- a/arch/riscv/mm/cacheflush.c
>>>>> +++ b/arch/riscv/mm/cacheflush.c
>>>>> @@ -122,7 +122,9 @@ void riscv_init_cbom_blocksize(void)
>>>>>                    }
>>>>>            }
>>>>>
>>>>> -       if (probed_block_size)
>>>>> +       if (probed_block_size) {
>>>>>                    riscv_cbom_block_size = probed_block_size;
>>>>> +               pr_info("riscv: Zicbom: Cache blocksize is %u bytes", probed_block_size);
>>>>> +       }
>>>>>     }
>>>>>     #endif
>>>>> --
>>>>> 2.37.2
>>>>>
>>>>
>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] RISC-V: Output cbom-block-size

[Heiko Stübner]

Am Dienstag, 6. September 2022, 11:42:11 CEST schrieb Conor.Dooley@microchip.com:
> On 06/09/2022 10:29, Andrew Jones wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > On Tue, Sep 06, 2022 at 09:00:20AM +0000, Conor.Dooley@microchip.com wrote:
> >> On 06/09/2022 09:55, Andrew Jones wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> On Tue, Sep 06, 2022 at 08:40:23AM +0000, Conor.Dooley@microchip.com wrote:
> >>>> On 06/09/2022 09:35, Andrew Jones wrote:
> >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>>
> >>>>> Provide an info message with the block size when the Zicbom extension is
> >>>>> present and the block size has been determined.
> >>>>
> >>>> Why might someone care about this?
> >>>
> >>> I was unaware of anywhere else besides hardware descriptions where this is
> >>> published. And, while dmesg isn't really publishing it in a way that is
> >>> useful to anything other than human readers either, it at least makes it
> >>> easy for a user to check it for sanity purposes (which is what I used it
> >>> for) or even for applying it if they want to write something that needs it
> >>> and the OS provides U-mode access to CMO.
> >>>
> >>> I'm not married to the idea, though, so if people would rather have less
> >>> logs than this information, then I'm fine with dropping the patch.
> >>
> >> I don't really care either way about logging it, if it helps people to
> >> be able to see it perhaps there's a better location than dmesg -
> >> would {debug,sys}fs be overkill?
> > 
> > Thinking about this some more, I think sysfs would probably be the better
> > way to go from the start. This patch should probably be dropped and I
> > can try to add a sysfs node. The hard part of that will be the naming...
> > How about
> > 
> >   /sys/devices/system/cpu/cpu*/cache/cmo_block_size
> 
> Seems sane to me, but I am oh-so-very-far from an expert here.
> Heiko might have a more qualified opinion.

I guess I'd more start with a pr_debug(). When debugging you
get the output and regular users won't care at all anyway.
Otherwise you can also just
	cat /proc/device-tree/cpus/cpu\@0/riscv\,cbom-block-size | xxd -p


Sysfs is whole different can of worms, as you create a new userspace
facing interface, which you need to support indefinitly.


Similar to Conor, I guess it would be interesting to me, what problem
you're trying to solve, as in my (simple) thinking, everybody that somehow
needs to check the block-size should have the knowledge to get it from
any of the dt representations we already have ;-) 


Heiko



> >> I was just more interested in the motivation behind the change itself.
> >> Maybe some of the above in the commit message wuld be nice?
> >>
> >>>
> >>> Thanks,
> >>> drew
> >>>
> >>>>
> >>>>>
> >>>>> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> >>>>> ---
> >>>>>     arch/riscv/mm/cacheflush.c | 4 +++-
> >>>>>     1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
> >>>>> index e5b087be1577..8595baf8e403 100644
> >>>>> --- a/arch/riscv/mm/cacheflush.c
> >>>>> +++ b/arch/riscv/mm/cacheflush.c
> >>>>> @@ -122,7 +122,9 @@ void riscv_init_cbom_blocksize(void)
> >>>>>                    }
> >>>>>            }
> >>>>>
> >>>>> -       if (probed_block_size)
> >>>>> +       if (probed_block_size) {
> >>>>>                    riscv_cbom_block_size = probed_block_size;
> >>>>> +               pr_info("riscv: Zicbom: Cache blocksize is %u bytes", probed_block_size);
> >>>>> +       }
> >>>>>     }
> >>>>>     #endif
> >>>>> --
> >>>>> 2.37.2
> >>>>>
> >>>>
> >>
> 
> 





_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/3] RISC-V: Output cbom-block-size

[Andrew Jones]

On Tue, Sep 06, 2022 at 04:34:49PM +0200, Heiko Stübner wrote:
> Am Dienstag, 6. September 2022, 11:42:11 CEST schrieb Conor.Dooley@microchip.com:
> > On 06/09/2022 10:29, Andrew Jones wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > > 
> > > On Tue, Sep 06, 2022 at 09:00:20AM +0000, Conor.Dooley@microchip.com wrote:
> > >> On 06/09/2022 09:55, Andrew Jones wrote:
> > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >>>
> > >>> On Tue, Sep 06, 2022 at 08:40:23AM +0000, Conor.Dooley@microchip.com wrote:
> > >>>> On 06/09/2022 09:35, Andrew Jones wrote:
> > >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >>>>>
> > >>>>> Provide an info message with the block size when the Zicbom extension is
> > >>>>> present and the block size has been determined.
> > >>>>
> > >>>> Why might someone care about this?
> > >>>
> > >>> I was unaware of anywhere else besides hardware descriptions where this is
> > >>> published. And, while dmesg isn't really publishing it in a way that is
> > >>> useful to anything other than human readers either, it at least makes it
> > >>> easy for a user to check it for sanity purposes (which is what I used it
> > >>> for) or even for applying it if they want to write something that needs it
> > >>> and the OS provides U-mode access to CMO.
> > >>>
> > >>> I'm not married to the idea, though, so if people would rather have less
> > >>> logs than this information, then I'm fine with dropping the patch.
> > >>
> > >> I don't really care either way about logging it, if it helps people to
> > >> be able to see it perhaps there's a better location than dmesg -
> > >> would {debug,sys}fs be overkill?
> > > 
> > > Thinking about this some more, I think sysfs would probably be the better
> > > way to go from the start. This patch should probably be dropped and I
> > > can try to add a sysfs node. The hard part of that will be the naming...
> > > How about
> > > 
> > >   /sys/devices/system/cpu/cpu*/cache/cmo_block_size
> > 
> > Seems sane to me, but I am oh-so-very-far from an expert here.
> > Heiko might have a more qualified opinion.
> 
> I guess I'd more start with a pr_debug(). When debugging you
> get the output and regular users won't care at all anyway.
> Otherwise you can also just
> 	cat /proc/device-tree/cpus/cpu\@0/riscv\,cbom-block-size | xxd -p
> 
> 
> Sysfs is whole different can of worms, as you create a new userspace
> facing interface, which you need to support indefinitly.
> 
> 
> Similar to Conor, I guess it would be interesting to me, what problem
> you're trying to solve, as in my (simple) thinking, everybody that somehow
> needs to check the block-size should have the knowledge to get it from
> any of the dt representations we already have ;-) 

Easy to get from DT, not so easy to get from ACPI.

Anyway, I'm fine with dropping this patch (I'll send a v2 without it to
make that clear). If we do ever want to enable CMO in U-mode, then this
will likely come up again, but then it'll have better justification to put
the size somewhere that applications can easily get it (and I believe that
will be sysfs).

Thanks,
drew


> 
> 
> Heiko
> 
> 
> 
> > >> I was just more interested in the motivation behind the change itself.
> > >> Maybe some of the above in the commit message wuld be nice?
> > >>
> > >>>
> > >>> Thanks,
> > >>> drew
> > >>>
> > >>>>
> > >>>>>
> > >>>>> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> > >>>>> ---
> > >>>>>     arch/riscv/mm/cacheflush.c | 4 +++-
> > >>>>>     1 file changed, 3 insertions(+), 1 deletion(-)
> > >>>>>
> > >>>>> diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
> > >>>>> index e5b087be1577..8595baf8e403 100644
> > >>>>> --- a/arch/riscv/mm/cacheflush.c
> > >>>>> +++ b/arch/riscv/mm/cacheflush.c
> > >>>>> @@ -122,7 +122,9 @@ void riscv_init_cbom_blocksize(void)
> > >>>>>                    }
> > >>>>>            }
> > >>>>>
> > >>>>> -       if (probed_block_size)
> > >>>>> +       if (probed_block_size) {
> > >>>>>                    riscv_cbom_block_size = probed_block_size;
> > >>>>> +               pr_info("riscv: Zicbom: Cache blocksize is %u bytes", probed_block_size);
> > >>>>> +       }
> > >>>>>     }
> > >>>>>     #endif
> > >>>>> --
> > >>>>> 2.37.2
> > >>>>>
> > >>>>
> > >>
> > 
> > 
> 
> 
> 
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv