On Tue, Sep 12, 2023 at 4:08 PM Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote: > > On Tue, Sep 12, 2023 at 09:33:57AM +0800, Guo Ren wrote: > > On Mon, Sep 11, 2023 at 8:53 PM Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote: > > > > I added the new "riscv,isa-extensions" property in part to make > > > communicating vendor extensions like this easier. Please try to use > > > that. "qspinlock" is software configuration though, the vendor extension > > > should focus on the guarantee of strong forward progress, since that is > > > the non-standard aspect of your IP. > > > > The qspinlock contains three paths: > > - Native qspinlock, this is your strong forward progress. > > - virt_spin_lock, for KVM guest when paravirt qspinlock disabled. > > https://lore.kernel.org/linux-riscv/20230910082911.3378782-9-guoren@xxxxxxxxxx/ > > - paravirt qspinlock, for KVM guest > > > > So, we need a software configuration here, "riscv,isa-extensions" is > > all about vendor extension. > > Ah right, yes it would only be able to be used to determine whether or > not the platform is capable of supporting these spinlocks, not whether or > not the kernel is a guest. I think I misinterpreted that snippet you posted, > thinking you were trying to disable your new spinlock for KVM, sorry. > On that note though, what about other sorts of guests? Will non-KVM > guests not also want to use this virt spinlock? I only put KVM guests here, and I can't answer other hypervisor that is another topic. > > Thanks, > Conor. -- Best Regards Guo Ren
