>>> On 21.03.18 at 18:57, wrote:
> On 21/03/18 05:46, Juergen Gross wrote:
>> On 20/03/18 18:22, Andrew Cooper wrote:
>>> On 20/03/18 16:58, Jan Beulich wrote:
>>> On 19.03.18 at 20:13, wrote:
> It is not entirely clear why this
On 21/03/18 05:46, Juergen Gross wrote:
> On 20/03/18 18:22, Andrew Cooper wrote:
>> On 20/03/18 16:58, Jan Beulich wrote:
>> On 19.03.18 at 20:13, wrote:
It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
"x86/AMD: Add support for
On 20/03/18 18:22, Andrew Cooper wrote:
> On 20/03/18 16:58, Jan Beulich wrote:
> On 19.03.18 at 20:13, wrote:
>>> It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
>>> "x86/AMD: Add support for AMD's OSVW feature in guests".
>>>
>>> At the
On 20/03/18 16:58, Jan Beulich wrote:
On 19.03.18 at 20:13, wrote:
>> It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
>> "x86/AMD: Add support for AMD's OSVW feature in guests".
>>
>> At the time, svm_handle_osvw() could have seen an
>>> On 19.03.18 at 20:13, wrote:
> It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
> "x86/AMD: Add support for AMD's OSVW feature in guests".
>
> At the time, svm_handle_osvw() could have seen an unexpected change in OSVW
> (not the case
It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
"x86/AMD: Add support for AMD's OSVW feature in guests".
At the time, svm_handle_osvw() could have seen an unexpected change in OSVW
(not the case now, due to the new CPUID Policy infrastructure), but even then,
it would