All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Kagan <rkagan@virtuozzo.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode
Date: Mon, 28 Jan 2019 11:30:20 +0000	[thread overview]
Message-ID: <20190128113017.GA2435@rkaganb.sw.ru> (raw)
In-Reply-To: <87bm44onnh.fsf@vitty.brq.redhat.com>

On Fri, Jan 25, 2019 at 02:46:42PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan <rkagan@virtuozzo.com> 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.

Roman.

  reply	other threads:[~2019-01-28 11:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-25 11:41 [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 11:41 ` [Qemu-devel] [PATCH RFC 1/8] Update linux headers (5.0-rc2) Vitaly Kuznetsov
2019-01-25 11:41 ` [Qemu-devel] [PATCH RFC 2/8] i386/kvm: add support for KVM_GET_SUPPORTED_HV_CPUID Vitaly Kuznetsov
2019-01-25 11:41 ` [Qemu-devel] [PATCH RFC 3/8] i386/kvm: move Hyper-V CPUID filling to hyperv_handle_properties() Vitaly Kuznetsov
2019-01-25 11:41 ` [Qemu-devel] [PATCH RFC 4/8] i386/kvm: Implement 'hv-all' pass-through mode Vitaly Kuznetsov
2019-01-25 12:47   ` Roman Kagan
2019-01-25 13:46     ` Vitaly Kuznetsov
2019-01-28 11:30       ` Roman Kagan [this message]
2019-01-28 13:54         ` Vitaly Kuznetsov
2019-01-28 18:22           ` Dr. David Alan Gilbert
2019-01-28 19:10             ` Eduardo Habkost
2019-01-29 15:25               ` Vitaly Kuznetsov
2019-01-29 15:20             ` Vitaly Kuznetsov
2019-01-29 15:28               ` Dr. David Alan Gilbert
2019-01-29 15:43             ` Daniel P. Berrangé
2019-01-25 11:41 ` [Qemu-devel] [PATCH RFC 5/8] i386/kvm: hv-evmcs requires hv-vapic Vitaly Kuznetsov
2019-01-25 11:41 ` [Qemu-devel] [PATCH RFC 6/8] i386/kvm: hv-stimer requires hv-time and hv-synic Vitaly Kuznetsov
2019-01-25 11:41 ` [Qemu-devel] [PATCH RFC 7/8] i386/kvm: hv-tlbflush/ipi require hv-vpindex Vitaly Kuznetsov
2019-01-25 11:41 ` [Qemu-devel] [PATCH RFC 8/8] i386/kvm: add support for Direct Mode for Hyper-V synthetic timers Vitaly Kuznetsov
2019-01-31 18:09 ` [Qemu-devel] [PATCH RFC 0/8] i386/kvm/hyper-v: refactor and implement 'hv-stimer-direct' and 'hv-all' enlightenments no-reply
2019-02-02 13:39   ` Vitaly Kuznetsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190128113017.GA2435@rkaganb.sw.ru \
    --to=rkagan@virtuozzo.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=vkuznets@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.