From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Roman Kagan <rkagan@virtuozzo.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>,
"Daniel P . Berrangé" <berrange@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 4/8] i386/kvm: implement 'hv-all' pass-through mode
Date: Fri, 05 Apr 2019 19:00:02 +0200 [thread overview]
Message-ID: <87pnq0ie0d.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20190405150659.GC20411@rkaganb.sw.ru>
Roman Kagan <rkagan@virtuozzo.com> writes:
> On Fri, Mar 29, 2019 at 03:18:28PM +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.
>
> The only one out of those "many cases" I can think of is when you've
> developed a new hyperv feature in the kernel and you want to test it
> with a version of QEMU that's not aware of it. Are there any others?
>
I can recall the following case I had: benchmark Windows guest
performance with different kernels like try to get the best number. As
these kernels were supporting different set of hv-* enlightenments I had
to do non-trivial work to figure out what's supported and adjust QEMU
command line accordingly.
Would've been much easier with 'hv-all'
>>
>> hv_cpuid_check_and_set() is modified to also set cpu->hyperv_* flags as
>> we may want to check them later (and we actually do for hv_runtime,
>> hv_synic,...).
>>
>> 'hv-all' is a development only feature, a migration blocker is added to
>> prevent issues while migrating between hosts with different feature sets.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> docs/hyperv.txt | 10 ++++
>> target/i386/cpu.c | 1 +
>> target/i386/cpu.h | 1 +
>> target/i386/kvm.c | 148 +++++++++++++++++++++++++++++++++++++---------
>> 4 files changed, 132 insertions(+), 28 deletions(-)
>>
>> diff --git a/docs/hyperv.txt b/docs/hyperv.txt
>> index 397f2517b8..d1299aba81 100644
>> --- a/docs/hyperv.txt
>> +++ b/docs/hyperv.txt
>> @@ -174,6 +174,16 @@ without the feature to find out if enabling it is beneficial.
>> Requires: hv-vapic
>>
>>
>> +4. Development features
>> +========================
>> +In some cases (e.g. during development) it may make sense to use QEMU in
>> +'pass-through' mode and give Windows guests all enlightenments currently
>> +supported by KVM. This pass-through mode is enabled by "hv-all" CPU flag.
>> +Note: enabling this flag effectively prevents migration as supported features
>> +may differ between target and destination.
>
> I find 'hv-passthrough' a more adequate name for this.
Sure, will adjust.
>
>> +Note: "hv-all" doesn't include 'hv-evmcs', it needs to be enabled explicitly.
>
> This is extremely confusing, when some features are more equal than
> others. I think it'd make more sense instead to support filtering out
> some features, like in "hv-passthrough,hv-evmcs=off".
hv-evmcs is probably the only enlightenment which is not an obvious
'win': when enabled, some features (e.g. posted interrupts) are getting
disabled. But as 'hv-all' is now a developer-only feature I see no
problem with enabling evmcs too.
--
Vitaly
WARNING: multiple messages have this Message-ID (diff)
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Roman Kagan <rkagan@virtuozzo.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 4/8] i386/kvm: implement 'hv-all' pass-through mode
Date: Fri, 05 Apr 2019 19:00:02 +0200 [thread overview]
Message-ID: <87pnq0ie0d.fsf@vitty.brq.redhat.com> (raw)
Message-ID: <20190405170002.teH20kgc7i37kFuvvam_wA8gdW3jElihQ1tW7jPQDEA@z> (raw)
In-Reply-To: <20190405150659.GC20411@rkaganb.sw.ru>
Roman Kagan <rkagan@virtuozzo.com> writes:
> On Fri, Mar 29, 2019 at 03:18:28PM +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.
>
> The only one out of those "many cases" I can think of is when you've
> developed a new hyperv feature in the kernel and you want to test it
> with a version of QEMU that's not aware of it. Are there any others?
>
I can recall the following case I had: benchmark Windows guest
performance with different kernels like try to get the best number. As
these kernels were supporting different set of hv-* enlightenments I had
to do non-trivial work to figure out what's supported and adjust QEMU
command line accordingly.
Would've been much easier with 'hv-all'
>>
>> hv_cpuid_check_and_set() is modified to also set cpu->hyperv_* flags as
>> we may want to check them later (and we actually do for hv_runtime,
>> hv_synic,...).
>>
>> 'hv-all' is a development only feature, a migration blocker is added to
>> prevent issues while migrating between hosts with different feature sets.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> docs/hyperv.txt | 10 ++++
>> target/i386/cpu.c | 1 +
>> target/i386/cpu.h | 1 +
>> target/i386/kvm.c | 148 +++++++++++++++++++++++++++++++++++++---------
>> 4 files changed, 132 insertions(+), 28 deletions(-)
>>
>> diff --git a/docs/hyperv.txt b/docs/hyperv.txt
>> index 397f2517b8..d1299aba81 100644
>> --- a/docs/hyperv.txt
>> +++ b/docs/hyperv.txt
>> @@ -174,6 +174,16 @@ without the feature to find out if enabling it is beneficial.
>> Requires: hv-vapic
>>
>>
>> +4. Development features
>> +========================
>> +In some cases (e.g. during development) it may make sense to use QEMU in
>> +'pass-through' mode and give Windows guests all enlightenments currently
>> +supported by KVM. This pass-through mode is enabled by "hv-all" CPU flag.
>> +Note: enabling this flag effectively prevents migration as supported features
>> +may differ between target and destination.
>
> I find 'hv-passthrough' a more adequate name for this.
Sure, will adjust.
>
>> +Note: "hv-all" doesn't include 'hv-evmcs', it needs to be enabled explicitly.
>
> This is extremely confusing, when some features are more equal than
> others. I think it'd make more sense instead to support filtering out
> some features, like in "hv-passthrough,hv-evmcs=off".
hv-evmcs is probably the only enlightenment which is not an obvious
'win': when enabled, some features (e.g. posted interrupts) are getting
disabled. But as 'hv-all' is now a developer-only feature I see no
problem with enabling evmcs too.
--
Vitaly
next prev parent reply other threads:[~2019-04-05 17:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190329141832.22882-1-vkuznets@redhat.com>
[not found] ` <20190329141832.22882-2-vkuznets@redhat.com>
2019-04-05 13:05 ` [Qemu-devel] [PATCH 1/8] i386/kvm: add support for KVM_GET_SUPPORTED_HV_CPUID Roman Kagan
2019-04-05 13:05 ` Roman Kagan
[not found] ` <20190329141832.22882-4-vkuznets@redhat.com>
2019-04-05 13:19 ` [Qemu-devel] [PATCH 3/8] i386/kvm: document existing Hyper-V enlightenments Roman Kagan
2019-04-05 13:19 ` Roman Kagan
2019-04-05 14:29 ` Vitaly Kuznetsov
2019-04-05 14:29 ` Vitaly Kuznetsov
[not found] ` <20190329141832.22882-5-vkuznets@redhat.com>
2019-04-05 15:07 ` [Qemu-devel] [PATCH 4/8] i386/kvm: implement 'hv-all' pass-through mode Roman Kagan
2019-04-05 15:07 ` Roman Kagan
2019-04-05 17:00 ` Vitaly Kuznetsov [this message]
2019-04-05 17:00 ` 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=87pnq0ie0d.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkagan@virtuozzo.com \
--cc=rth@twiddle.net \
/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.