qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/2] i386/kvm: add support for Hyper-V reenli


From: Roman Kagan
Subject: Re: [Qemu-devel] [PATCH v2 1/2] i386/kvm: add support for Hyper-V reenlightenment MSRs
Date: Wed, 21 Mar 2018 13:58:44 +0300
User-agent: Mutt/1.9.2 (2017-12-15)

On Tue, Mar 20, 2018 at 03:16:52PM -0300, Eduardo Habkost wrote:
> On Mon, Mar 19, 2018 at 06:29:08PM +0100, Vitaly Kuznetsov wrote:
> > Roman Kagan <address@hidden> writes:
> > > (This is also a problem with has_msr_hv_frequencies, and is in general a
> > > long-standing issue of hv_* properties being done differently from the
> > > rest of CPUID features.)
> > 
> > Suggestions? (To be honest I don't really like us adding new hv_*
> > property for every new Hyper-V feature we support. I doubt anyone needs
> > 'partial' Hyper-V emulation. It would be nice to have a single versioned
> > 'hv' feature implying everything. We may then forbid migrations to older
> > hv versions. But I don't really know the history of why we decided to go
> > with a separate hv_* for every feature we add).
> 
> You will need "partial" emulation if you want to support
> live-migration to/from a host where the KVM or QEMU don't support
> all the features from the current host.
> 
> Is this something the current Hyper-V code already supports, or
> it's something known to be broken?

There's at least one case I mentioned above where it's broken, but, as
Paolo pointed out, the real Windows guests wouldn't notice because they
didn't use the feature due to missing INVTSC.

I myself haven't tested all possible combinations of hv_* flags and KVM
versions, but from code inspection I don't immediately see anything else
that's obviously broken in this regard.

Roman.



reply via email to

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