Re: [Xen-devel] [PATCH v7 07/11] pvqspinlock, x86: Allow unfair queue spinlock in a XEN guest

[Waiman Long <waiman.long@xxxxxx>]

On 03/19/2014 04:28 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 19, 2014 at 04:14:05PM -0400, Waiman Long wrote:
> > This patch adds a XEN init function to activate the unfair queue
> > spinlock in a XEN guest when the PARAVIRT_UNFAIR_LOCKS kernel config
> > option is selected.
> >
> > Signed-off-by: Waiman Long<Waiman.Long@xxxxxx>
> > ---
> >   arch/x86/xen/setup.c |   19 +++++++++++++++++++
> >   1 files changed, 19 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 0982233..66bb6f5 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -625,3 +625,22 @@ void __init xen_arch_setup(void)
> >         numa_off = 1;
> >   #endif
> >   }
> > +
> > +#ifdef CONFIG_PARAVIRT_UNFAIR_LOCKS
> > +/*
> > + * Enable unfair lock if running in a Xen guest
> > + */
> > +static __init int xen_unfair_locks_init_jump(void)
> > +{
> > +       /*
> > +        * Disable unfair lock if not running in a PV domain
> > +        */
> > +       if (!xen_pv_domain())
> > +               return 0;
> I would just make this 'xen_domain'. Not sure why you need
> to have it only for PV while the PVHVM guests can also use it?
The compilation of the setup.c file should have implied xen_domain 
already (at least HVM). The check is added to make sure that unfair lock 
won't be enabled on bare metal. As for PVHVM, is there a way to detect 
it is running as such which is distinct from HVM?
> Would it also make sense to use the same printk statement
> that the KVM has?
Yes, I can add a printk statement like KVM.

-Longman

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel