From: Juergen Gross <jgross@suse.com>
To: David Vrabel <david.vrabel@citrix.com>,
linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Cc: jeremy@goop.org, jdelvare@suse.com, peterz@infradead.org,
x86@kernel.org, pali.rohar@gmail.com, rusty@rustcorp.com.au,
virtualization@lists.linux-foundation.org, chrisw@sous-sol.org,
mingo@redhat.com, tglx@linutronix.de, Douglas_Warzecha@dell.com,
hpa@zytor.com, akataria@vmware.com, boris.ostrovsky@oracle.com,
linux@roeck-us.net
Subject: Re: [PATCH v4 4/6] xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu
Date: Tue, 5 Apr 2016 12:01:50 +0200 [thread overview]
Message-ID: <57038D0E.1040708__773.635661653493$1459850603$gmane$org@suse.com> (raw)
In-Reply-To: <57038927.1030205@citrix.com>
On 05/04/16 11:45, David Vrabel wrote:
> On 05/04/16 06:10, Juergen Gross wrote:
>> Some hardware models (e.g. Dell Studio 1555 laptops) require calls to
>> the firmware to be issued on cpu 0 only. As Dom0 might have to use
>> these calls, add xen_pin_vcpu() to achieve this functionality.
>>
>> In case either the domain doesn't have the privilege to make the
>> related hypercall or the hypervisor isn't supporting it, issue a
>> warning once and disable further pinning attempts.
> [...]
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -1885,6 +1885,45 @@ static void xen_set_cpu_features(struct cpuinfo_x86 *c)
>> }
>> }
>>
>> +static void xen_pin_vcpu(int cpu)
>> +{
>> + static bool disable_pinning;
>> + struct sched_pin_override pin_override;
>> + int ret;
>> +
>> + if (disable_pinning)
>> + return;
>> +
>> + pin_override.pcpu = cpu;
>> + ret = HYPERVISOR_sched_op(SCHEDOP_pin_override, &pin_override);
>
> /* Ignore errors when removing override. */
Okay.
>> + if (cpu < 0)
>> + return;
>> +
>> + switch (ret) {
>> + case -ENOSYS:
>> + pr_warn("The kernel tried to call a function on physical cpu %d, but Xen isn't\n"
>> + "supporting this. In case of problems you might consider vcpu pinning.\n",
>> + cpu);
>> + disable_pinning = true;
>> + break;
>> + case -EPERM:
>> + WARN(1, "Trying to pin vcpu without having privilege to do so\n");
>> + disable_pinning = true;
>> + break;
>> + case -EINVAL:
>> + case -EBUSY:
>> + pr_warn("The kernel tried to call a function on physical cpu %d, but this cpu\n"
>> + "seems not to be available. Please check your Xen cpu configuration.\n",
>> + cpu);
>> + break;
>> + case 0:
>> + break;
>> + default:
>> + WARN(1, "rc %d while trying to pin vcpu\n", ret);
>> + disable_pinning = true;
>> + }
>
> These messages are a bit wordy for my taste and since they don't say
> what function failed or what driver is affected they're not as useful as
Did you notice I used WARN() for the cases where a usage error is to
be suspected? This will print a stack backtrace helping to identify the
driver.
I can work on the message text, of course.
> they could be. I'd probably turn these all into:
>
> if (cpu >= 0 && ret < 0) {
> pr_warn("Failed to pin VCPU %d to physical CPU %d: %d",
> smp_processor_id(), cpu, ret);
> disable_pinning = true;
> }
No, I don't think this is a good idea. In the EINVAL or EBUSY case a
simple Xen admin command might be enough to make the next call succeed.
I don't want to disable pinning in this case.
> And look at getting the user of this API to print a more useful error.
>
> "i8k: unable to call SMM BIOS on physical CPU %d: %d"
TBH: I think this should be done by another patch. This is something
the maintainers of the callers' code should decide.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-05 10:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1459833007-11618-1-git-send-email-jgross@suse.com>
2016-04-05 5:10 ` [PATCH v4 1/6] xen: sync xen header Juergen Gross
2016-04-05 5:10 ` [PATCH v4 2/6] virt, sched: add generic vcpu pinning support Juergen Gross
2016-04-05 5:10 ` [PATCH v4 3/6] smp: add function to execute a function synchronously on a cpu Juergen Gross
2016-04-05 5:10 ` [PATCH v4 4/6] xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu Juergen Gross
2016-04-05 5:10 ` [PATCH v4 5/6] dcdbas: make use of smp_call_on_cpu() Juergen Gross
2016-04-05 5:10 ` [PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k Juergen Gross
[not found] ` <1459833007-11618-4-git-send-email-jgross@suse.com>
2016-04-05 8:11 ` [PATCH v4 3/6] smp: add function to execute a function synchronously on a cpu Peter Zijlstra
[not found] ` <20160405081107.GH3448@twins.programming.kicks-ass.net>
2016-04-05 10:05 ` Juergen Gross
[not found] ` <1459833007-11618-2-git-send-email-jgross@suse.com>
2016-04-05 9:34 ` [PATCH v4 1/6] xen: sync xen header David Vrabel
[not found] ` <1459833007-11618-5-git-send-email-jgross@suse.com>
2016-04-05 9:45 ` [PATCH v4 4/6] xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu David Vrabel
[not found] ` <57038927.1030205@citrix.com>
2016-04-05 10:01 ` Juergen Gross [this message]
[not found] ` <57038D0E.1040708@suse.com>
2016-04-05 10:03 ` David Vrabel
[not found] ` <1459833007-11618-7-git-send-email-jgross@suse.com>
2016-04-05 14:54 ` [PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k Guenter Roeck
[not found] ` <20160405145414.GB27359@roeck-us.net>
2016-04-05 19:31 ` Pali Rohár
[not found] ` <201604052131.52765@pali>
2016-04-21 10:57 ` Pali Rohár
[not found] ` <20160421105724.GK29406@pali>
2016-04-21 13:12 ` Juergen Gross
[not found] ` <5718D1D4.3040309@suse.com>
2016-04-21 13:27 ` Pali Rohár
[not found] ` <20160421132735.GR29406@pali>
2016-05-09 14:37 ` Juergen Gross
[not found] ` <5730A08D.60100@suse.com>
2016-05-12 8:51 ` Pali Rohár
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='57038D0E.1040708__773.635661653493$1459850603$gmane$org@suse.com' \
--to=jgross@suse.com \
--cc=Douglas_Warzecha@dell.com \
--cc=akataria@vmware.com \
--cc=boris.ostrovsky@oracle.com \
--cc=chrisw@sous-sol.org \
--cc=david.vrabel@citrix.com \
--cc=hpa@zytor.com \
--cc=jdelvare@suse.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mingo@redhat.com \
--cc=pali.rohar@gmail.com \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).