Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode

[Eduardo Habkost]

On Mon, Jan 28, 2019 at 06:22:30PM +0000, Dr. David Alan Gilbert wrote:
> * Vitaly Kuznetsov (address@hidden) wrote:
> > Roman Kagan <address@hidden> writes:
> > 
> > > On Fri, Jan 25, 2019 at 02:46:42PM +0100, Vitaly Kuznetsov wrote:
> > >> Roman Kagan <address@hidden> writes:
> > >> 
> > >> > On Fri, Jan 25, 2019 at 12:41:51PM +0100, Vitaly Kuznetsov wrote:
> > >> >> In many case we just want to give Windows guests all currently 
> > >> >> supported
> > >> >> Hyper-V enlightenments and that's where this new mode may come handy. 
> > >> >> We
> > >> >> pass through what was returned by KVM_GET_SUPPORTED_HV_CPUID.
> > >> >
> > >> > How is the compatibility ensured on migration between kernels reporting
> > >> > different feature sets?
> > >> 
> > >> AFAIU we don't change anything in this regard (or, my intention was to
> > >> not change anything): hv-all is converted to the individual hv-*
> > >> properties (hv_cpuid_check_and_set()) actually sets cpu->hyperv_* flags
> > >> according to what's supported by kernel so when we migrate we will
> > >> require all these features supported.
> > >
> > > Migration relies on the upper layer to run the destination QEMU with the
> > > identical command line (except for -incoming) as the source, and QEMU is
> > > then supposed to set up identical environment in the target VM as was in
> > > the source, or refuse to start if that's impossible.  (If I'm
> > > misunderstanding this Dave (cc-d) may want to correct me.)
> > >
> > > AFAICS this hv-all attribute will enable different feature sets
> > > depending on the kernel it's run on, so the migration between different
> > > kernels will appear to succeed, but the guest may suddenly encounter an
> > > incompatible change in the environment.
> > 
> > With 'hv-all' I'm trying to achieve behavior similar to '-cpu host' and
> > AFAIK these VMs are migratable 'at your own risk' (if you do it directly
> > from qemu). Libvirt (or whatever upper layer), however, would do CPU
> > feature comparison and in case you have less features on the destination
> > host than you had on the source code it will forbid the migration. I
> > think if this also works for Hyper-V features than were fine.
> > 
> > Dave, feel free to tell me I'm completely wrong with my assumptions)
> 
> It does sound like -cpu host, but -cpu host does come with a health
> warning and we often get subtle screwups where it doesn't quite behave
> the same on the two sides, also qemu now warns (and with 'enforce'
> enforces) a check at it's level rather than relying on libvirt.
> 
> So hmm, yes it sounds like -cpu host, but I'd generally say it's not a
> great thing to copy unless you're really really careful.
> For example, in the -cpu host world people might have two machines
> they think are the same - but then they find out one has HT disabled
> or nesting enabled and so they're not actually the same.
> 
> I'm not sure what the equivalent bear traps are in the Hyper-V world,
> but I'd be surprised if there weren't any; for example what happens
> when someone upgrades one of their hosts to some minor version that
> adds/removes a feature?
> 
> Also, how does libvirt figure out that the features are actually the
> same - does it need a bunch of detection code?

If libvirt is involved, it's much simpler and safer to use
something like <cpu mode="host-model">, which generates a
migration-safe CPU configuration based on the current host.  Live
migration support with "-cpu host" is only useful for experiments
and carefully controlled environments.

Is there a real need to make hv-all migratable?  What would be
the use case, exactly?  If there's no clear use case, I would
recommend making it a migration blocker.

-- 
Eduardo