On Thu, Nov 02, 2017 at 07:24:16PM +0100, Paolo Bonzini wrote: > On 02/11/2017 19:08, Eduardo Valentin wrote: > > On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote: > >> On 02/11/2017 18:45, Eduardo Valentin wrote: > >>> Currently, the existing qspinlock implementation will fallback to > >>> test-and-set if the hypervisor has not set the PV_UNHALT flag. > >>> > >>> This patch gives the opportunity to guest kernels to select > >>> between test-and-set and the regular queueu fair lock implementation > >>> based on the PV_DEDICATED KVM feature flag. When the PV_DEDICATED > >>> flag is not set, the code will still fall back to test-and-set, > >>> but when the PV_DEDICATED flag is set, the code will use > >>> the regular queue spinlock implementation. > >> > >> Have you seen Waiman's series that lets you specify this on the guest > >> command line instead? Would this be acceptable for your use case? > > > > No, can you please share a link to it? is it already merged to tip/master? > > [PATCH-tip v2 0/2] x86/paravirt: Enable users to choose PV lock type > https://lkml.org/lkml/2017/11/1/655 > > >> (In other words, is there a difference for you between making the host > >> vs. guest administrator toggle the feature? "@amazon.com" means you are > >> the host admin, how would you use it?) > > > > The way I think of this is this is a flag set by host side so the > > guest adapts accordingly. > > > > If the admin in guest side wants to ignore what the host is > > flagging, that is a different story. > > Okay, this makes sense. But perhaps it should be a separate CPUID leaf, > such as "configuration hints", rather than properly a feature. Oh OK, you don't think this starts to deviate from the feature concept. But would the PV_UNHALT also go to "configuration hints" bucket? Another way to see this is we have three locking feature options to select from, so we need at least two bits here. > > Paolo -- All the best, Eduardo Valentin
