similar to: [PATCH v2 0/6] Support calling functions on dedicated physical cpu

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote: > --- a/kernel/smp.c > +++ b/kernel/smp.c > @@ -14,6 +14,7 @@ > #include <linux/smp.h> > #include <linux/cpu.h> > #include <linux/sched.h> > +#include <linux/hypervisor.h> > > #include "smpboot.h" > > @@ -758,9 +759,14 @@ struct smp_sync_call_struct { >

On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote: > --- a/kernel/smp.c > +++ b/kernel/smp.c > @@ -14,6 +14,7 @@ > #include <linux/smp.h> > #include <linux/cpu.h> > #include <linux/sched.h> > +#include <linux/hypervisor.h> > > #include "smpboot.h" > > @@ -758,9 +759,14 @@ struct smp_sync_call_struct { >

On Fri, Apr 01, 2016 at 10:28:46AM +0200, Juergen Gross wrote: > On 01/04/16 09:43, Peter Zijlstra wrote: > > On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote: > >> --- a/kernel/smp.c > >> +++ b/kernel/smp.c > >> @@ -14,6 +14,7 @@ > >> #include <linux/smp.h> > >> #include <linux/cpu.h> > >> #include

On Fri, Apr 01, 2016 at 10:28:46AM +0200, Juergen Gross wrote: > On 01/04/16 09:43, Peter Zijlstra wrote: > > On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote: > >> --- a/kernel/smp.c > >> +++ b/kernel/smp.c > >> @@ -14,6 +14,7 @@ > >> #include <linux/smp.h> > >> #include <linux/cpu.h> > >> #include

Add generic virtualization support for pinning the current vcpu to a specified physical cpu. As this operation isn't performance critical (a very limited set of operations like BIOS calls and SMIs is expected to need this) just add a hypervisor specific indirection. Such a pinning should last as short as possible as it might block sensible vcpu scheduling and maybe other hypervisor functions

Add generic virtualization support for pinning the current vcpu to a specified physical cpu. As this operation isn't performance critical (a very limited set of operations like BIOS calls and SMIs is expected to need this) just add a hypervisor specific indirection. Such a pinning should last as short as possible as it might block sensible vcpu scheduling and maybe other hypervisor functions

On 01/04/16 09:43, Peter Zijlstra wrote: > On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote: >> --- a/kernel/smp.c >> +++ b/kernel/smp.c >> @@ -14,6 +14,7 @@ >> #include <linux/smp.h> >> #include <linux/cpu.h> >> #include <linux/sched.h> >> +#include <linux/hypervisor.h> >> >> #include

On 01/04/16 10:44, Peter Zijlstra wrote: > On Fri, Apr 01, 2016 at 10:28:46AM +0200, Juergen Gross wrote: >> On 01/04/16 09:43, Peter Zijlstra wrote: >>> On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote: >>>> --- a/kernel/smp.c >>>> +++ b/kernel/smp.c >>>> @@ -14,6 +14,7 @@ >>>> #include <linux/smp.h>

>>> On 21.03.16 at 13:24, <JGross at suse.com> wrote: > @@ -758,9 +759,14 @@ struct smp_sync_call_struct { > static void smp_call_sync_callback(struct work_struct *work) > { > struct smp_sync_call_struct *sscs; > + unsigned int cpu = smp_processor_id(); So this obtains the vCPU number, yet ... > sscs = container_of(work, struct smp_sync_call_struct, work);

On 21/03/16 14:42, Jan Beulich wrote: >>>> On 21.03.16 at 13:24, <JGross at suse.com> wrote: >> @@ -758,9 +759,14 @@ struct smp_sync_call_struct { >> static void smp_call_sync_callback(struct work_struct *work) >> { >> struct smp_sync_call_struct *sscs; >> + unsigned int cpu = smp_processor_id(); > > So this obtains the vCPU number, yet

>>> On 21.03.16 at 13:24, <JGross at suse.com> wrote: > @@ -758,9 +759,14 @@ struct smp_sync_call_struct { > static void smp_call_sync_callback(struct work_struct *work) > { > struct smp_sync_call_struct *sscs; > + unsigned int cpu = smp_processor_id(); So this obtains the vCPU number, yet ... > sscs = container_of(work, struct smp_sync_call_struct, work);

Use smp_call_on_cpu() to raise SMI on cpu 0. Make call secure by adding get_online_cpus() to avoid e.g. suspend resume cycles in between. Signed-off-by: Juergen Gross <jgross at suse.com> --- V4: add call to get_online_cpus() --- drivers/firmware/dcdbas.c | 51 ++++++++++++++++++++++++----------------------- 1 file changed, 26 insertions(+), 25 deletions(-) diff --git