From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Jan Beulich <JBeulich@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: kevin.tian@intel.com, jun.nakajima@intel.com,
suravee.suthikulpanit@amd.com, xen-devel@lists.xen.org
Subject: Re: [PATCH] x86/vpmu: Add get/put_vpmu() and VPMU_ENABLED
Date: Fri, 17 Feb 2017 09:17:17 -0500 [thread overview]
Message-ID: <3e8e61ce-564e-9499-d896-942854769c7a@oracle.com> (raw)
In-Reply-To: <58A6C1E9020000780013B1B2@prv-mh.provo.novell.com>
On 02/17/2017 03:27 AM, Jan Beulich wrote:
>>>> On 16.02.17 at 19:09, <boris.ostrovsky@oracle.com> wrote:
>> On 02/16/2017 12:09 PM, Andrew Cooper wrote:
>>> Second, if it is available, has the toolstack chosen to allow the domain
>>> to use it. This should determine whether features/information are
>>> visible in CPUID.
>>
>> You mean if toolstack masks out leaf 0xa on Intel? I chould check this
>> in get_vpmu(). Is this information available by the time
>> vcpu_initialise() runs?
>
> You shouldn't rely on this, even if it happened to be that way
> right now. Instead you'd have to adjust accordingly when CPUID
> info gets updated by the tool stack (update_domain_cpuid_info()
> as the root hook point).
Right, that's what I was going to do --- destroy VPMU if CPUID indicates
no support.
> Which gets us to another point: Shouldn't
> we disallow CPUID info updates after the guest started running?
> Or do we mean to trust the tool stack to not do this if it doesn't
> want to confuse a guest?
I believe currently it's the latter. I don't see anything preventing
CPUID update to a running guest (except for pausing it while the update
is in progress).
>
>>> Finally, if vpmu is permitted, has the domain turned it on.
>>
>> HVM domains always do and PV domains essentially too.
>
> How that? Or are you talking of just modern Linux guests?
The newer ones.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-02-17 14:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-16 14:59 [PATCH] x86/vpmu: Add get/put_vpmu() and VPMU_ENABLED Boris Ostrovsky
2017-02-16 16:59 ` Jan Beulich
2017-02-16 17:09 ` Andrew Cooper
2017-02-16 18:09 ` Boris Ostrovsky
2017-02-17 8:27 ` Jan Beulich
2017-02-17 14:17 ` Boris Ostrovsky [this message]
2017-02-17 15:58 ` Andrew Cooper
2017-02-17 16:37 ` Boris Ostrovsky
2017-02-16 17:31 ` Boris Ostrovsky
2017-02-17 8:28 ` Jan Beulich
2017-02-17 14:24 ` Boris Ostrovsky
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=3e8e61ce-564e-9499-d896-942854769c7a@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=jun.nakajima@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.