From: "Lan, Tianyu" <tianyu.lan@intel.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: afaerber@suse.de, pbonzini@redhat.com, rth@twiddle.net,
jan.kiszka@web.de, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [PATCH] Qemu/KVM: Remove x2apic feature from CPU model when kernel_irqchip is off
Date: Tue, 1 Mar 2016 22:47:02 +0800 [thread overview]
Message-ID: <56D5AB66.6010308@intel.com> (raw)
In-Reply-To: <20160301140038.GA3632@thinpad.lan.raisama.net>
On 3/1/2016 10:00 PM, Eduardo Habkost wrote:
> On Mon, Feb 29, 2016 at 10:56:04AM +0800, Lan Tianyu wrote:
>> On 2016年02月27日 03:54, Eduardo Habkost wrote:
>>> On Thu, Feb 25, 2016 at 11:15:12PM +0800, Lan Tianyu wrote:
>>>> x2apic feature is in the kvm_default_props and automatically added to all
>>>> CPU models when KVM is enabled. But userspace devices don't support x2apic
>>>> which can't be enabled without the in-kernel irqchip. It will trigger
>>>> warning of "host doesn't support requested feature: CPUID.01H:ECX.x2apic
>>>> [bit 21]" when kernel_irqchip is off. This patch is to fix it via removing
>>>> x2apic feature when kernel_irqchip is off.
>>>>
>>>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>>>> ---
>>>> target-i386/cpu.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>>>> index c78f824..298fb62 100644
>>>> --- a/target-i386/cpu.c
>>>> +++ b/target-i386/cpu.c
>>>> @@ -2125,6 +2125,10 @@ static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp)
>>>>
>>>> /* Special cases not set in the X86CPUDefinition structs: */
>>>> if (kvm_enabled()) {
>>>> + if (!kvm_irqchip_in_kernel()) {
>>>> + x86_cpu_change_kvm_default("x2apic", "off");
>>>
>>> This should be NULL instead of "off".
>>
>> I tried "NULL" before. But some cpus modules(E,G SandyBridge,
>> IvyBridge, haswell) already have x2apic feature in their default
>> features of struct X86CPUDefinition, passing "NULL" is not to add x2apic
>> feature to the cpu module and will not help to remove x2apic feature for
>> these cpu modules. So I changed "NULL" to "off".
>
> In this case, I suggest we remove x2apic from these CPU models to
> avoid confusion, as the presence of the flag in the table makes
> no difference at all (this can be done in a separate patch).
>
> If we do that, NULL and "off" would have the same results, but
> NULL is clearer, IMO. NULL simply disables the KVM-specific hack
> (so we don't touch the property anymore), but "off" adds a new
> TCG-specific hack. I will submit that as a follow-up patch.
Yes, that sounds reasonable. Thanks for your review.
>
> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>
>>
>>> Otherwise, the warning will
>>> be disabled if using "-cpu ...,+x2apic".
>>>
>>
>> kvm_arch_get_supported_cpuid() always returns no x2apic support when
>> kernel_irqchip is off and so it still triggers warning with "-cpu
>> ...,+x2apic".
>>
>> #qemu-system-x86_64 -cpu qemu64,+x2apic -machine kernel-irqchip=off
>> warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic
>> [bit 21]
>
> You are right. The +x2apic flag is applied after
> x86_cpu_load_def() runs. My mistake.
>
WARNING: multiple messages have this Message-ID (diff)
From: "Lan, Tianyu" <tianyu.lan@intel.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, jan.kiszka@web.de,
pbonzini@redhat.com, afaerber@suse.de, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH] Qemu/KVM: Remove x2apic feature from CPU model when kernel_irqchip is off
Date: Tue, 1 Mar 2016 22:47:02 +0800 [thread overview]
Message-ID: <56D5AB66.6010308@intel.com> (raw)
In-Reply-To: <20160301140038.GA3632@thinpad.lan.raisama.net>
On 3/1/2016 10:00 PM, Eduardo Habkost wrote:
> On Mon, Feb 29, 2016 at 10:56:04AM +0800, Lan Tianyu wrote:
>> On 2016年02月27日 03:54, Eduardo Habkost wrote:
>>> On Thu, Feb 25, 2016 at 11:15:12PM +0800, Lan Tianyu wrote:
>>>> x2apic feature is in the kvm_default_props and automatically added to all
>>>> CPU models when KVM is enabled. But userspace devices don't support x2apic
>>>> which can't be enabled without the in-kernel irqchip. It will trigger
>>>> warning of "host doesn't support requested feature: CPUID.01H:ECX.x2apic
>>>> [bit 21]" when kernel_irqchip is off. This patch is to fix it via removing
>>>> x2apic feature when kernel_irqchip is off.
>>>>
>>>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>>>> ---
>>>> target-i386/cpu.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>>>> index c78f824..298fb62 100644
>>>> --- a/target-i386/cpu.c
>>>> +++ b/target-i386/cpu.c
>>>> @@ -2125,6 +2125,10 @@ static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp)
>>>>
>>>> /* Special cases not set in the X86CPUDefinition structs: */
>>>> if (kvm_enabled()) {
>>>> + if (!kvm_irqchip_in_kernel()) {
>>>> + x86_cpu_change_kvm_default("x2apic", "off");
>>>
>>> This should be NULL instead of "off".
>>
>> I tried "NULL" before. But some cpus modules(E,G SandyBridge,
>> IvyBridge, haswell) already have x2apic feature in their default
>> features of struct X86CPUDefinition, passing "NULL" is not to add x2apic
>> feature to the cpu module and will not help to remove x2apic feature for
>> these cpu modules. So I changed "NULL" to "off".
>
> In this case, I suggest we remove x2apic from these CPU models to
> avoid confusion, as the presence of the flag in the table makes
> no difference at all (this can be done in a separate patch).
>
> If we do that, NULL and "off" would have the same results, but
> NULL is clearer, IMO. NULL simply disables the KVM-specific hack
> (so we don't touch the property anymore), but "off" adds a new
> TCG-specific hack. I will submit that as a follow-up patch.
Yes, that sounds reasonable. Thanks for your review.
>
> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>
>>
>>> Otherwise, the warning will
>>> be disabled if using "-cpu ...,+x2apic".
>>>
>>
>> kvm_arch_get_supported_cpuid() always returns no x2apic support when
>> kernel_irqchip is off and so it still triggers warning with "-cpu
>> ...,+x2apic".
>>
>> #qemu-system-x86_64 -cpu qemu64,+x2apic -machine kernel-irqchip=off
>> warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic
>> [bit 21]
>
> You are right. The +x2apic flag is applied after
> x86_cpu_load_def() runs. My mistake.
>
next prev parent reply other threads:[~2016-03-01 14:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 15:15 [PATCH] Qemu/KVM: Remove x2apic feature from CPU model when kernel_irqchip is off Lan Tianyu
2016-02-25 15:15 ` [Qemu-devel] " Lan Tianyu
2016-02-26 9:56 ` Paolo Bonzini
2016-02-26 9:56 ` [Qemu-devel] " Paolo Bonzini
2016-02-26 19:54 ` Eduardo Habkost
2016-02-26 19:54 ` [Qemu-devel] " Eduardo Habkost
2016-02-29 2:56 ` Lan Tianyu
2016-02-29 2:56 ` [Qemu-devel] " Lan Tianyu
2016-03-01 14:00 ` Eduardo Habkost
2016-03-01 14:00 ` [Qemu-devel] " Eduardo Habkost
2016-03-01 14:47 ` Lan, Tianyu [this message]
2016-03-01 14:47 ` Lan, Tianyu
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=56D5AB66.6010308@intel.com \
--to=tianyu.lan@intel.com \
--cc=afaerber@suse.de \
--cc=ehabkost@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--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.