From: "Jan Beulich" <JBeulich@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: kevin.tian@intel.com, andrew.cooper3@citrix.com,
dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org,
Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com,
dgdegra@tycho.nsa.gov
Subject: Re: [PATCH v25 04/15] x86/VPMU: Interface for setting PMU mode and flags
Date: Tue, 23 Jun 2015 09:26:11 +0100 [thread overview]
Message-ID: <558934430200007800087F56@mail.emea.novell.com> (raw)
In-Reply-To: <55883382.6040908@oracle.com>
>>> On 22.06.15 at 18:10, <boris.ostrovsky@oracle.com> wrote:
> On 06/22/2015 11:10 AM, Jan Beulich wrote:
>>
>>> + switch ( op )
>>> + {
>>> + case XENPMU_mode_set:
>>> + {
>>> + if ( (pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV)) ||
>>> + (hweight64(pmu_params.val) > 1) )
>>> + return -EINVAL;
>>> +
>>> + /* 32-bit dom0 can only sample itself. */
>>> + if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
>>> + return -EINVAL;
>>> +
>>> + spin_lock(&vpmu_lock);
>>> +
>>> + /*
>>> + * We can always safely switch between XENPMU_MODE_SELF and
>>> + * XENPMU_MODE_HV while other VPMUs are active.
>>> + */
>>> + if ( (vpmu_count == 0) || (vpmu_mode == pmu_params.val) ||
>>> + ((vpmu_mode ^ pmu_params.val) ==
>>> + (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
>>> + vpmu_mode = pmu_params.val;
>>> + else
>>> + {
>> I think this would better be
>>
>> if ( (vpmu_count == 0) ||
>> ((vpmu_mode ^ pmu_params.val) ==
>> (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
>> vpmu_mode = pmu_params.val;
>> else if ( vpmu_mode != pmu_params.val )
>> {
>>
>> But there's no need to re-submit just because of this (it could be
>> changed upon commit if you agree).
>
> This will generate an error (with a message to the log) even if we keep
> the mode unchanged, something that I wanted to avoid. (Same thing for
> XENPMU_feature_set, which is what Kevin mentioned last time).
I don't see this: The only difference to the code you have is -
afaics - that my variant avoids the pointless write to vpmu_mode.
>> Or wait - I just checked again, and while I thought this was long
>> addressed I still don't seen struct xen_pmu_params "pad" field
>> being checked to be zero as input, and being stored as zero when
>> only an output. Did this get lost? Did I forget about a reason why
>> this isn't being done? Unless the latter is the case, the ack above
>> is dependent upon this getting fixed.
>
> Yes, we did talk about this and as result I added major version check
> (which I should have had there anyway): if we decide to start using this
> field we'd need to increment the major version.
Okay then.
Jan
next prev parent reply other threads:[~2015-06-23 8:26 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 18:44 [PATCH v25 00/15] x86/PMU: Xen PMU PV(H) support Boris Ostrovsky
2015-06-19 18:44 ` [PATCH v25 01/15] common/symbols: Export hypervisor symbols to privileged guest Boris Ostrovsky
2015-06-19 18:44 ` [PATCH v25 02/15] x86/VPMU: Add public xenpmu.h Boris Ostrovsky
2015-06-19 18:44 ` [PATCH v25 03/15] x86/VPMU: Make vpmu not HVM-specific Boris Ostrovsky
2015-06-19 18:44 ` [PATCH v25 04/15] x86/VPMU: Interface for setting PMU mode and flags Boris Ostrovsky
2015-06-22 15:10 ` Jan Beulich
2015-06-22 16:10 ` Boris Ostrovsky
2015-06-23 8:26 ` Jan Beulich [this message]
2015-06-24 2:17 ` Boris Ostrovsky
2015-07-07 7:16 ` Dietmar Hahn
2015-07-09 1:27 ` Tian, Kevin
2015-06-19 18:44 ` [PATCH v25 05/15] x86/VPMU: Initialize VPMUs with __initcall Boris Ostrovsky
2015-07-08 11:48 ` Dietmar Hahn
2015-07-09 6:04 ` Tian, Kevin
2015-06-19 18:44 ` [PATCH v25 06/15] x86/VPMU: Initialize PMU for PV(H) guests Boris Ostrovsky
2015-07-08 12:20 ` Dietmar Hahn
2015-06-19 18:44 ` [PATCH v25 07/15] x86/VPMU: Save VPMU state for PV guests during context switch Boris Ostrovsky
2015-06-22 15:14 ` Jan Beulich
2015-07-08 5:51 ` Dietmar Hahn
2015-06-19 18:44 ` [PATCH v25 08/15] x86/VPMU: When handling MSR accesses, leave fault injection to callers Boris Ostrovsky
2015-07-08 6:11 ` Dietmar Hahn
2015-06-19 18:44 ` [PATCH v25 09/15] x86/VPMU: Add support for PMU register handling on PV guests Boris Ostrovsky
2015-06-19 18:44 ` [PATCH v25 10/15] x86/VPMU: Use pre-computed masks when checking validity of MSRs Boris Ostrovsky
2015-07-08 6:49 ` Dietmar Hahn
2015-06-19 18:44 ` [PATCH v25 11/15] VPMU/AMD: Check MSR values before writing to hardware Boris Ostrovsky
2015-07-08 15:35 ` Aravind Gopalakrishnan
2015-06-19 18:44 ` [PATCH v25 12/15] x86/VPMU: Handle PMU interrupts for PV(H) guests Boris Ostrovsky
2015-06-22 15:20 ` Jan Beulich
2015-07-09 12:19 ` Dietmar Hahn
2015-06-19 18:44 ` [PATCH v25 13/15] x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr Boris Ostrovsky
2015-07-09 6:13 ` Tian, Kevin
2015-06-19 18:44 ` [PATCH v25 14/15] x86/VPMU: Add privileged PMU mode Boris Ostrovsky
2015-07-09 6:13 ` Tian, Kevin
2015-07-09 12:38 ` Dietmar Hahn
2015-06-19 18:44 ` [PATCH v25 15/15] x86/VPMU: Move VPMU files up from hvm/ directory Boris Ostrovsky
2015-07-08 8:03 ` [PATCH v25 00/15] x86/PMU: Xen PMU PV(H) support Jan Beulich
2015-07-10 9:13 ` Dietmar Hahn
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=558934430200007800087F56@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=Aravind.Gopalakrishnan@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=dietmar.hahn@ts.fujitsu.com \
--cc=kevin.tian@intel.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=xen-devel@lists.xen.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).