On 2019-10-10 00:50:09 [+0200], Paolo Bonzini wrote:
> > Also, taking advantage of this feature requires changes which just
> > landed in qemu's master branch.
>
> That's not a big deal, every QEMU supports every kernel and vice versa.
That is correct. My point was that the visibility of this cha
On 09/10/19 23:40, Sebastian Andrzej Siewior wrote:
>>> const u32 kvm_cpuid_8000_0008_ebx_x86_features =
>>> + F(XSAVEERPTR) |
>>> F(WBNOINVD) | F(AMD_IBPB) | F(AMD_IBRS) | F(AMD_SSBD) |
>>> F(VIRT_SSBD) |
>>> F(AMD_SSB_NO) | F(AMD_STIBP) | F(AMD_STIBP_ALWAYS_
On 2019-10-09 23:15:07 [+0200], Paolo Bonzini wrote:
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -479,6 +479,7 @@ static inline int __do_cpuid_func(struct
> > kvm_cpuid_entry2 *entry, u32 function,
> >
> > /* cpuid 0x8008.ebx */
> > const u32 kvm_cpuid_8000_0
On 09/10/19 19:05, Sasha Levin wrote:
> From: Sebastian Andrzej Siewior
>
> [ Upstream commit 504ce1954fba888936c9d13ccc1e3db9b8f613d5 ]
>
> I was surprised to see that the guest reported `fxsave_leak' while the
> host did not. After digging deeper I noticed that the bits are simply
> masked out
From: Sebastian Andrzej Siewior
[ Upstream commit 504ce1954fba888936c9d13ccc1e3db9b8f613d5 ]
I was surprised to see that the guest reported `fxsave_leak' while the
host did not. After digging deeper I noticed that the bits are simply
masked out during enumeration.
The XSAVEERPTR feature is actu
5 matches
Mail list logo