From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Fix a possible copy-paste error in arm_smccc_smc's first argument (a0)
for OPTEE_SMC_DISABLE_SHM_CACHE case.
This error causes Linux > v5.14-rc5 (b5c10dd04b7418793517e3286cde5c04759a86de
optee: Clear stale cache entries during initialization) to stuck
repeatedly issuing OPTEE_SMC_DISABLE_SHM_CACHE call and waiting for
the result to be OPTEE_SMC_RETURN_ENOTAVAIL which will never happen.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
I wonder whether this patch wants backporting to the old versions
since OPTEE support went in.
---
xen/arch/arm/tee/optee.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 3453615..6df0d44 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -1692,7 +1692,7 @@ static bool optee_handle_call(struct cpu_user_regs *regs)
return true;
case OPTEE_SMC_DISABLE_SHM_CACHE:
- arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
+ arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
OPTEE_CLIENT_ID(current->domain), &resp);
set_user_reg(regs, 0, resp.a0);
if ( resp.a0 == OPTEE_SMC_RETURN_OK ) {
--
2.7.4
Hi Oleksandr, > On 27 Sep 2021, at 14:54, Oleksandr Tyshchenko <olekstysh@gmail.com> wrote: > > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > Fix a possible copy-paste error in arm_smccc_smc's first argument (a0) > for OPTEE_SMC_DISABLE_SHM_CACHE case. > > This error causes Linux > v5.14-rc5 (b5c10dd04b7418793517e3286cde5c04759a86de > optee: Clear stale cache entries during initialization) to stuck > repeatedly issuing OPTEE_SMC_DISABLE_SHM_CACHE call and waiting for > the result to be OPTEE_SMC_RETURN_ENOTAVAIL which will never happen. > > Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Sound like a reasonable change :-) Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Cheers Bertrand > --- > I wonder whether this patch wants backporting to the old versions > since OPTEE support went in. > --- > xen/arch/arm/tee/optee.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > index 3453615..6df0d44 100644 > --- a/xen/arch/arm/tee/optee.c > +++ b/xen/arch/arm/tee/optee.c > @@ -1692,7 +1692,7 @@ static bool optee_handle_call(struct cpu_user_regs *regs) > return true; > > case OPTEE_SMC_DISABLE_SHM_CACHE: > - arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > + arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > OPTEE_CLIENT_ID(current->domain), &resp); > set_user_reg(regs, 0, resp.a0); > if ( resp.a0 == OPTEE_SMC_RETURN_OK ) { > -- > 2.7.4 > >
Hi Oleksandr, Oleksandr Tyshchenko <olekstysh@gmail.com> writes: > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > Fix a possible copy-paste error in arm_smccc_smc's first argument (a0) > for OPTEE_SMC_DISABLE_SHM_CACHE case. > > This error causes Linux > v5.14-rc5 (b5c10dd04b7418793517e3286cde5c04759a86de > optee: Clear stale cache entries during initialization) to stuck > repeatedly issuing OPTEE_SMC_DISABLE_SHM_CACHE call and waiting for > the result to be OPTEE_SMC_RETURN_ENOTAVAIL which will never happen. > > Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > --- > I wonder whether this patch wants backporting to the old versions > since OPTEE support went in. > --- > xen/arch/arm/tee/optee.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > index 3453615..6df0d44 100644 > --- a/xen/arch/arm/tee/optee.c > +++ b/xen/arch/arm/tee/optee.c > @@ -1692,7 +1692,7 @@ static bool optee_handle_call(struct cpu_user_regs *regs) > return true; > > case OPTEE_SMC_DISABLE_SHM_CACHE: > - arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > + arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > OPTEE_CLIENT_ID(current->domain), &resp); > set_user_reg(regs, 0, resp.a0); > if ( resp.a0 == OPTEE_SMC_RETURN_OK ) { -- Volodymyr Babchuk at EPAM
On Mon, 27 Sep 2021, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > Fix a possible copy-paste error in arm_smccc_smc's first argument (a0) > for OPTEE_SMC_DISABLE_SHM_CACHE case. > > This error causes Linux > v5.14-rc5 (b5c10dd04b7418793517e3286cde5c04759a86de > optee: Clear stale cache entries during initialization) to stuck > repeatedly issuing OPTEE_SMC_DISABLE_SHM_CACHE call and waiting for > the result to be OPTEE_SMC_RETURN_ENOTAVAIL which will never happen. > > Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> I added Fixes: and Backport: tags to the commit > --- > I wonder whether this patch wants backporting to the old versions > since OPTEE support went in. > --- > xen/arch/arm/tee/optee.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > index 3453615..6df0d44 100644 > --- a/xen/arch/arm/tee/optee.c > +++ b/xen/arch/arm/tee/optee.c > @@ -1692,7 +1692,7 @@ static bool optee_handle_call(struct cpu_user_regs *regs) > return true; > > case OPTEE_SMC_DISABLE_SHM_CACHE: > - arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > + arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > OPTEE_CLIENT_ID(current->domain), &resp); > set_user_reg(regs, 0, resp.a0); > if ( resp.a0 == OPTEE_SMC_RETURN_OK ) { > -- > 2.7.4 >
Hi Stefano, On 28/09/2021 06:52, Stefano Stabellini wrote: > On Mon, 27 Sep 2021, Oleksandr Tyshchenko wrote: >> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >> >> Fix a possible copy-paste error in arm_smccc_smc's first argument (a0) >> for OPTEE_SMC_DISABLE_SHM_CACHE case. >> >> This error causes Linux > v5.14-rc5 (b5c10dd04b7418793517e3286cde5c04759a86de >> optee: Clear stale cache entries during initialization) to stuck >> repeatedly issuing OPTEE_SMC_DISABLE_SHM_CACHE call and waiting for >> the result to be OPTEE_SMC_RETURN_ENOTAVAIL which will never happen. >> >> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > Acked-by: Stefano Stabellini <sstabellini@kernel.org> > > I added Fixes: and Backport: tags to the commit Per SUPPORT.MD, OP-TEE is still a technical preview. So I would argue that we should not do any backport because the feature itself is not officially considered supported. That said, what's missing to make the feature officially supported? Cheers, -- Julien Grall
On Wed, 6 Oct 2021, Julien Grall wrote: > Hi Stefano, > > On 28/09/2021 06:52, Stefano Stabellini wrote: > > On Mon, 27 Sep 2021, Oleksandr Tyshchenko wrote: > > > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > > > > > Fix a possible copy-paste error in arm_smccc_smc's first argument (a0) > > > for OPTEE_SMC_DISABLE_SHM_CACHE case. > > > > > > This error causes Linux > v5.14-rc5 > > > (b5c10dd04b7418793517e3286cde5c04759a86de > > > optee: Clear stale cache entries during initialization) to stuck > > > repeatedly issuing OPTEE_SMC_DISABLE_SHM_CACHE call and waiting for > > > the result to be OPTEE_SMC_RETURN_ENOTAVAIL which will never happen. > > > > > > Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > > > Acked-by: Stefano Stabellini <sstabellini@kernel.org> > > > > I added Fixes: and Backport: tags to the commit > Per SUPPORT.MD, OP-TEE is still a technical preview. So I would argue that we > should not do any backport because the feature itself is not officially > considered supported. Good point! > That said, what's missing to make the feature officially supported? If Oleksandr is also happy to make OP-TEE support in Xen "Supported" in SUPPORT.md I'd be happy with that too. Specifically I suggest to change it to: Status: Supported, not security supported Security Support is a bit of a heavy process and I am thinking that "Supported, not security supported" would be an excellent next step.
On 07.10.21 01:42, Stefano Stabellini wrote: Hi Stefano, Julien. > On Wed, 6 Oct 2021, Julien Grall wrote: >> Hi Stefano, >> >> On 28/09/2021 06:52, Stefano Stabellini wrote: >>> On Mon, 27 Sep 2021, Oleksandr Tyshchenko wrote: >>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >>>> >>>> Fix a possible copy-paste error in arm_smccc_smc's first argument (a0) >>>> for OPTEE_SMC_DISABLE_SHM_CACHE case. >>>> >>>> This error causes Linux > v5.14-rc5 >>>> (b5c10dd04b7418793517e3286cde5c04759a86de >>>> optee: Clear stale cache entries during initialization) to stuck >>>> repeatedly issuing OPTEE_SMC_DISABLE_SHM_CACHE call and waiting for >>>> the result to be OPTEE_SMC_RETURN_ENOTAVAIL which will never happen. >>>> >>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >>> Acked-by: Stefano Stabellini <sstabellini@kernel.org> >>> >>> I added Fixes: and Backport: tags to the commit >> Per SUPPORT.MD, OP-TEE is still a technical preview. So I would argue that we >> should not do any backport because the feature itself is not officially >> considered supported. > Good point! > > >> That said, what's missing to make the feature officially supported? > If Oleksandr is also happy to make OP-TEE support in Xen "Supported" in > SUPPORT.md I'd be happy with that too. Specifically I suggest to change > it to: > > Status: Supported, not security supported > > Security Support is a bit of a heavy process and I am thinking that > "Supported, not security supported" would be an excellent next step. I would be happy, and can send a formal patch. But I am not an expert in this code. As a user I can say that OP-TEE mediator works perfectly fine, but let's wait for the input from Volodymyr, (looks like there are some TODO left in the code and I have no idea what are the implications) -- Regards, Oleksandr Tyshchenko
Hi Oleksandr, Stefano, Oleksandr <olekstysh@gmail.com> writes: > On 07.10.21 01:42, Stefano Stabellini wrote: > > Hi Stefano, Julien. > >> On Wed, 6 Oct 2021, Julien Grall wrote: >>> Hi Stefano, >>> >>> On 28/09/2021 06:52, Stefano Stabellini wrote: >>>> On Mon, 27 Sep 2021, Oleksandr Tyshchenko wrote: >>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >>>>> >>>>> Fix a possible copy-paste error in arm_smccc_smc's first argument (a0) >>>>> for OPTEE_SMC_DISABLE_SHM_CACHE case. >>>>> >>>>> This error causes Linux > v5.14-rc5 >>>>> (b5c10dd04b7418793517e3286cde5c04759a86de >>>>> optee: Clear stale cache entries during initialization) to stuck >>>>> repeatedly issuing OPTEE_SMC_DISABLE_SHM_CACHE call and waiting for >>>>> the result to be OPTEE_SMC_RETURN_ENOTAVAIL which will never happen. >>>>> >>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >>>> Acked-by: Stefano Stabellini <sstabellini@kernel.org> >>>> >>>> I added Fixes: and Backport: tags to the commit >>> Per SUPPORT.MD, OP-TEE is still a technical preview. So I would argue that we >>> should not do any backport because the feature itself is not officially >>> considered supported. >> Good point! >> >> >>> That said, what's missing to make the feature officially supported? >> If Oleksandr is also happy to make OP-TEE support in Xen "Supported" in >> SUPPORT.md I'd be happy with that too. Specifically I suggest to change >> it to: >> >> Status: Supported, not security supported >> >> Security Support is a bit of a heavy process and I am thinking that >> "Supported, not security supported" would be an excellent next step. > > I would be happy, and can send a formal patch. But I am not an expert > in this code. I'm will be happy with this too. We are using this mediator in our projects and I know that OP-TEE community adopted tests for virtualization in theirs CI stack. So this is kind of official now. Also, I helped other people to bring up virtualization on theirs platforms, so there are other users for this feature besides EPAM and Linaro. > (looks like there are some TODO left in the code and I have no idea > what are the implications) Well, there were a lot of TODOs when I submitted initial implementation. At that time it indeed wasn't ready for production. But I eventually fixed almost all of them. Only one left now. It is about very unlikely situation when one of guest pages in mapped at PA=0. I'm not sure that is even possible at all. -- Volodymyr Babchuk at EPAM
© 2016 - 2024 Red Hat, Inc.