lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 27 Apr 2018 12:03:21 +0200 From: Paolo Bonzini <pbonzini@...hat.com> To: Jim Mattson <jmattson@...gle.com>, "Raslan, KarimAllah" <karahmed@...zon.de> Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "tglx@...utronix.de" <tglx@...utronix.de>, "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>, "rkrcmar@...hat.com" <rkrcmar@...hat.com> Subject: Re: [PATCH 2/2] kvm: nVMX: Introduce KVM_CAP_STATE On 27/04/2018 00:28, Jim Mattson wrote: > The other thing that comes to mind is that there are some new fields > in the VMCS12 since I first implemented this. One potentially > troublesome field is the VMX preemption timer. If the current timer > value is not saved on VM-exit, then it won't be stashed in the shadow > VMCS12 by sync_vmcs12. Post-migration, the timer will be reset to its > original value. > > Do we care? Is this any different from what happens on real hardware > when there's an SMI? According to the SDM, this appears to be exacty > what happens when the dual-monitor treatment of SMIs and SMM is > active, but it's not clear what happens with the default treatment of > SMIs and SMM. I think it should be the same, because the preemption timer countdown is not part of the VMX-critical state. Paolo
Powered by blists - more mailing lists