Re: [PATCH 0/2] RISC-V: KVM: Require alternatives

[Andrew Jones <ajones@ventanamicro.com>]

On Fri, Mar 24, 2023 at 11:52:13AM +0000, Conor Dooley wrote:
> On Fri, Mar 24, 2023 at 12:32:59PM +0100, Andrew Jones wrote:
> > On Thu, Mar 23, 2023 at 05:57:14PM +0000, Conor Dooley wrote:
> > > On Wed, Mar 22, 2023 at 07:40:14PM +0000, Conor Dooley wrote:
> > > > On Wed, Mar 22, 2023 at 08:28:56PM +0100, Andrew Jones wrote:
> > > > > KVM makes use of riscv_has_extension_unlikely() to check for the
> > > > > svinval extension. riscv_has_extension_unlikely() is built on
> > > > > alternatives, which means KVM should ensure alternatives support
> > > > > is available.
> > > > > 
> > > > > The first patch takes the opportunity to cleanup KVM's select
> > > > > list. The second patch selects RISCV_ALTERNATIVE.
> > > > 
> > > > Reminds me, I need to re-submit my patch doing that for the top-level
> > > > RISC-V Kconfig...
> > > > For the pair:
> > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > 
> > > Actually, I would like to take this back for patch 2.
> > > Per the discussion on the other thread about XIP [1], I don't think
> > > that KVM should be selecting alternatives like this.
> > > Would you mind if I picked up these patches & submitted them as a v2,
> > > alongside a patch trying to make sure that we do not clip the wings of
> > > of XIP kernels by selecting RISCV_ALTERNATIVE?
> > 
> > Hi Conor,
> > 
> > I take it that resubmitting these patches is no longer part of the plan.
> 
> Ah crap, sorry. I meant to reply here after submitting and forgot.
> 
> > Should I rebase on "[PATCH v1 0/2] RISC-V: Fixes for
> > riscv_has_extension[un]likely()'s alternative dependency" and change the
> > select to a depends on?
> 
> I don't think you need to. Does KVM actually make use of alternatives,
> other than for riscv_has_extension_unlikely(), that are not gated by
> extension/erratum specific config options?
> 
> With my patch 2/2, alternatives are always enabled for !XIP_KERNEL
> builds, and will fall back to the "slow" path in
> riscv_has_extension_unlikely() otherwise.
> If KVM doesn't need alternatives for another reason, I don't think you
> need to introduce a dependency on them and just inherit the decision
> made by CONFIG_RISCV.

Ack, thanks, Conor.

Anup, we can either drop patch 2/2 or the whole series, as you like.

Thanks,
drew

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