[PATCH 1/2] arm: cpu: Add optional CMOs by VA

[Tom Rini]

On Tue, Feb 07, 2023 at 05:06:39PM +0000, Marc Zyngier wrote:
> On Tue, 07 Feb 2023 16:40:05 +0000,
> Tom Rini <trini at konsulko.com> wrote:
> > 
> > On Tue, Feb 07, 2023 at 04:35:25PM +0000, Marc Zyngier wrote:
> > > On 2023-02-07 16:20, Ying-Chun Liu (PaulLiu) wrote:
> > > > Exposing set/way cache maintenance to a virtual machine is unsafe, not
> > > > least because the instructions are not permission-checked but also
> > > > because they are not broadcast between CPUs. Consequently, KVM traps and
> > > > emulates such maintenance in the host kernel using by-VA operations and
> > > > looping over the stage-2 page-tables. However, when running under
> > > > protected KVM, these instructions are not able to be emulated and will
> > > > instead result in an exception being delivered to the guest.
> > > > 
> > > > Introduce CONFIG_CMO_BY_VA_ONLY so that virtual platforms can select
> > > > this option and perform by-VA cache maintenance instead of using the
> > > > set/way instructions.
> > > > 
> > > > Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu at linaro.org>
> > > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > > Signed-off-by: Will Deacon <willdeacon at google.com>
> > > > Cc: Tom Rini <trini at konsulko.com>
> > > 
> > > The sign-off chain looks pretty odd. Either you are the author
> > > of this patch, and I have nothing to do on the sign-off list,
> > > or I'm the author and the authorship is wrong. Similar things
> > > would apply for Will.
> > > 
> > > So which one is it?
> > 
> > As my first guess here is copy and adopting code from Linux, this is
> > not following the documented procedure here:
> > https://u-boot.readthedocs.io/en/latest/develop/sending_patches.html#attributing-code-copyrights-signing
> >
> > Which if not sufficiently clear, please ask / suggest changes to. I see
> > right now it isn't specific about cc'ing the original authors (who may,
> > or may not, be interested, so blanket policy doesn't apply) but I would
> > hope is clear enough that what's done in this example isn't right.
> 
> No, this really is u-boot code written as part of Android, from where
> the patch has been directly lifted[1].
> 
> Same goes for Pierre-Clement's patch that is part of the same series.
> 
> I'm not overly attached to this code (I have bad memories from it),
> but I think the OP may be unaware of these rules. In any case, I'm
> supportive of this code making it in upstream u-boot. I just want it
> to be done correctly.
> 
> Thanks,
> 
> 	M.
> 
> [1] https://android.googlesource.com/platform/external/u-boot/+/db5507f47f4f57f766d52f753ff2cc761afc213b

Oh, hummm. I guess whatever the normal policy for upstreaming patches
from an Android kernel tree, to mainline, would be the starting point
here? Referencing the Android tree would be good too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230207/b1ad386b/attachment.sig>