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 (liran.alon@xxxxxxxxxx) 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 <liran.alon@xxxxxxxxxx>
> >>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> >>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> >>
> >> 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
