qemu-devel
[Top][All Lists]
Advanced

[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


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH] KVM: x86: Add support for save/load MSR_SMI_COUNT
Date: Tue, 24 Jul 2018 11:48:39 -0300
User-agent: Mutt/1.9.2 (2017-12-15)

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?

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]