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 <rka...@virtuozzo.com> 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.