On 19/02/2018 14:35, David Woodhouse wrote:
> On Mon, 2018-02-19 at 14:10 +0100, Paolo Bonzini wrote:
>>> Hardware seems like a reasonable place to get the default value (cf.
>>> the VMX capability MSRs).
>>
>> There are some differences:
>>
>> - a zero value for ARCH_CAPABILITIES should be safe,
On 19/02/2018 14:35, David Woodhouse wrote:
> On Mon, 2018-02-19 at 14:10 +0100, Paolo Bonzini wrote:
>>> Hardware seems like a reasonable place to get the default value (cf.
>>> the VMX capability MSRs).
>>
>> There are some differences:
>>
>> - a zero value for ARCH_CAPABILITIES should be safe,
On Mon, 2018-02-19 at 14:10 +0100, Paolo Bonzini wrote:
> > Hardware seems like a reasonable place to get the default value (cf.
> > the VMX capability MSRs).
>
> There are some differences:
>
> - a zero value for ARCH_CAPABILITIES should be safe, while a zero value
> for VMX capabilities
On Mon, 2018-02-19 at 14:10 +0100, Paolo Bonzini wrote:
> > Hardware seems like a reasonable place to get the default value (cf.
> > the VMX capability MSRs).
>
> There are some differences:
>
> - a zero value for ARCH_CAPABILITIES should be safe, while a zero value
> for VMX capabilities
On 16/02/2018 17:29, Jim Mattson wrote:
> On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote:
>
>> Uhm, taking contents from the hardware is wrong (guess why---live
>> migration). I'll send a revert of those two lines.
>
> Hardware seems like a reasonable place to get
On 16/02/2018 17:29, Jim Mattson wrote:
> On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote:
>
>> Uhm, taking contents from the hardware is wrong (guess why---live
>> migration). I'll send a revert of those two lines.
>
> Hardware seems like a reasonable place to get the default value (cf.
On Fri, 2018-02-16 at 08:29 -0800, Jim Mattson wrote:
> On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote:
>
> > Uhm, taking contents from the hardware is wrong (guess why---live
> > migration). I'll send a revert of those two lines.
>
> Hardware seems like a
On Fri, 2018-02-16 at 08:29 -0800, Jim Mattson wrote:
> On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote:
>
> > Uhm, taking contents from the hardware is wrong (guess why---live
> > migration). I'll send a revert of those two lines.
>
> Hardware seems like a reasonable place to get the
On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote:
> Uhm, taking contents from the hardware is wrong (guess why---live
> migration). I'll send a revert of those two lines.
Hardware seems like a reasonable place to get the default value (cf.
the VMX capability MSRs).
On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote:
> Uhm, taking contents from the hardware is wrong (guess why---live
> migration). I'll send a revert of those two lines.
Hardware seems like a reasonable place to get the default value (cf.
the VMX capability MSRs). Should these two lines
On 06/02/2018 18:29, David Woodhouse wrote:
> From: KarimAllah Ahmed
>
> Intel processors use MSR_IA32_ARCH_CAPABILITIES MSR to indicate RDCL_NO
> (bit 0) and IBRS_ALL (bit 1). This is a read-only MSR. By default the
> contents will come directly from the hardware, but
On 06/02/2018 18:29, David Woodhouse wrote:
> From: KarimAllah Ahmed
>
> Intel processors use MSR_IA32_ARCH_CAPABILITIES MSR to indicate RDCL_NO
> (bit 0) and IBRS_ALL (bit 1). This is a read-only MSR. By default the
> contents will come directly from the hardware, but user-space can still
>
From: KarimAllah Ahmed
Intel processors use MSR_IA32_ARCH_CAPABILITIES MSR to indicate RDCL_NO
(bit 0) and IBRS_ALL (bit 1). This is a read-only MSR. By default the
contents will come directly from the hardware, but user-space can still
override it.
[dwmw2: The bit in
From: KarimAllah Ahmed
Intel processors use MSR_IA32_ARCH_CAPABILITIES MSR to indicate RDCL_NO
(bit 0) and IBRS_ALL (bit 1). This is a read-only MSR. By default the
contents will come directly from the hardware, but user-space can still
override it.
[dwmw2: The bit in
14 matches
Mail list logo