[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-throu
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode |
Date: |
Mon, 28 Jan 2019 17:10:17 -0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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
- [Qemu-devel] [PATCH RFC 0/8] i386/kvm/hyper-v: refactor and implement 'hv-stimer-direct' and 'hv-all' enlightenments, Vitaly Kuznetsov, 2019/01/25
- [Qemu-devel] [PATCH RFC 2/8] i386/kvm: add support for KVM_GET_SUPPORTED_HV_CPUID, Vitaly Kuznetsov, 2019/01/25
- [Qemu-devel] [PATCH RFC 3/8] i386/kvm: move Hyper-V CPUID filling to hyperv_handle_properties(), Vitaly Kuznetsov, 2019/01/25
- [Qemu-devel] [PATCH RFC 5/8] i386/kvm: hv-evmcs requires hv-vapic, Vitaly Kuznetsov, 2019/01/25
- [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Vitaly Kuznetsov, 2019/01/25
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Roman Kagan, 2019/01/25
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Vitaly Kuznetsov, 2019/01/25
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Roman Kagan, 2019/01/28
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Vitaly Kuznetsov, 2019/01/28
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Dr. David Alan Gilbert, 2019/01/28
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode,
Eduardo Habkost <=
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Vitaly Kuznetsov, 2019/01/29
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Vitaly Kuznetsov, 2019/01/29
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Dr. David Alan Gilbert, 2019/01/29
- Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode, Daniel P . Berrangé, 2019/01/29
[Qemu-devel] [PATCH RFC 6/8] i386/kvm: hv-stimer requires hv-time and hv-synic, Vitaly Kuznetsov, 2019/01/25
[Qemu-devel] [PATCH RFC 7/8] i386/kvm: hv-tlbflush/ipi require hv-vpindex, Vitaly Kuznetsov, 2019/01/25
[Qemu-devel] [PATCH RFC 8/8] i386/kvm: add support for Direct Mode for Hyper-V synthetic timers, Vitaly Kuznetsov, 2019/01/25
[Qemu-devel] [PATCH RFC 1/8] Update linux headers (5.0-rc2), Vitaly Kuznetsov, 2019/01/25
Re: [Qemu-devel] [PATCH RFC 0/8] i386/kvm/hyper-v: refactor and implement 'hv-stimer-direct' and 'hv-all' enlightenments, no-reply, 2019/01/31