On 02/17/2017 10:58 AM, Andrew Cooper wrote:
On 17/02/17 14:17, Boris Ostrovsky wrote:
On 02/17/2017 03:27 AM, Jan Beulich wrote:
On 16.02.17 at 19:09, 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.
On 17/02/17 14:17, Boris Ostrovsky wrote:
>
>
> On 02/17/2017 03:27 AM, Jan Beulich wrote:
> On 16.02.17 at 19:09, 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 w
On 02/17/2017 03:28 AM, Jan Beulich wrote:
On 16.02.17 at 18:31, wrote:
On 02/16/2017 11:59 AM, Jan Beulich wrote:
Also this new model basically limits the opportunity to change the
mode to the case where no guest at all is running, iiuc. Previously
this would have been possible with any num
On 02/17/2017 03:27 AM, Jan Beulich wrote:
On 16.02.17 at 19:09, 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 too
>>> On 16.02.17 at 18:31, wrote:
> On 02/16/2017 11:59 AM, Jan Beulich wrote:
>> Also this new model basically limits the opportunity to change the
>> mode to the case where no guest at all is running, iiuc. Previously
>> this would have been possible with any number of guests running,
>> as long
>>> On 16.02.17 at 19:09, 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 In
On 02/16/2017 12:09 PM, Andrew Cooper wrote:
On 16/02/17 16:59, Jan Beulich wrote:
On 16.02.17 at 15:59, wrote:
vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
bit. This is problematic:
* For HVM guests
On 16/02/17 16:59, Jan Beulich wrote:
On 16.02.17 at 15:59, wrote:
>> vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
>> for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
>> bit. This is problematic:
>> * For HVM guests VPMU context is allocated lazily,
On 02/16/2017 11:59 AM, Jan Beulich wrote:
On 16.02.17 at 15:59, wrote:
vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
bit. This is problematic:
* For HVM guests VPMU context is allocated lazily, during
>>> On 16.02.17 at 15:59, wrote:
> vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
> for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
> bit. This is problematic:
> * For HVM guests VPMU context is allocated lazily, during the first
> access to VPMU MSRs. S
vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
bit. This is problematic:
* For HVM guests VPMU context is allocated lazily, during the first
access to VPMU MSRs. Since the leaf is typically queried before gu
11 matches
Mail list logo
