[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] KVM: x86: Add support for save/load MSR_SMI_COU
Re: [Qemu-devel] [PATCH] KVM: x86: Add support for save/load MSR_SMI_COUNT
Tue, 24 Jul 2018 11:48:39 -0300
On Tue, Jul 24, 2018 at 04:40:15PM +0200, Paolo Bonzini wrote:
> On 24/07/2018 16:39, Eduardo Habkost wrote:
> > On Tue, Jul 24, 2018 at 12:29:12PM +0100, Dr. David Alan Gilbert wrote:
> >> * Liran Alon (address@hidden) wrote:
> >>> This MSR returns the number of #SMIs that occurred on
> >>> CPU since boot.
> >>> KVM commit 52797bf9a875 ("KVM: x86: Add emulation of MSR_SMI_COUNT")
> >>> introduced support for emulating this MSR.
> >>> This commit adds support for QEMU to save/load this
> >>> MSR for migration purposes.
> >>> Signed-off-by: Liran Alon <address@hidden>
> >>> Reviewed-by: Konrad Rzeszutek Wilk <address@hidden>
> >>> Signed-off-by: Konrad Rzeszutek Wilk <address@hidden>
> >> Note this breaks 2.12->2.11 migration if SMM is enabled
> >> with a:
> >> qemu-system-x86_64: error while loading state for instance 0x0 of device
> >> 'cpu'
> > Right, the MSR can't be enabled unconditionally.
> > It looks like there's no CPUID bit for reporting the MSR as
> > available? How exactly would guests know if the MSR is really
> > safe to use?
> As far as we know, the only guest that uses it is ESX. Like most other
> MSRs, the guest should in general be ready for it to cause a #GP fault.
True, guests are normally ready to handle both cases: 1) MSR
working as in bare metal; 2) MSR reads causing a #GP fault.
But with the current KVM code, old machine-types can't implement
either of those cases, but only a 3rd option: MSR read won't
cause #GP, but MSR can unexpectedly reset due to live migration.
Are guests ready to handle that?