From: Jan Kiszka <jan.kiszka@web.de>
To: Gleb Natapov <gleb@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86 <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH] x86: Make x2APIC support depend on interrupt remapping or guest support
Date: Sun, 06 Jul 2014 17:49:09 +0200 [thread overview]
Message-ID: <53B96FF5.2050107@web.de> (raw)
In-Reply-To: <20140706154112.GO18167@minantech.com>
[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]
On 2014-07-06 17:41, Gleb Natapov wrote:
> On Sun, Jul 06, 2014 at 05:24:27PM +0200, Jan Kiszka wrote:
>> On 2014-07-06 17:12, Gleb Natapov wrote:
>>> On Sat, Jul 05, 2014 at 09:47:54AM +0200, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> We are able to use x2APIC mode in the absence of interrupt remapping on
>>>> certain hypervisors. So it if fine to disable IRQ_REMAP without having
>>>> to give up x2APIC support.
>>> FWIW I did similar thing back when I added x2apic to KVM:
>>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-06/msg14579.html
>>> But was advised against it.
>>
>> I don't get the point from that thread.
> It is not architectural to use x2apic without irq remapping, so Suresh
Slightly off-topic for this patch: Is this dependency documented
somewhere? I guess there are broken systems where it can fail, but none
of the (Intel) boxes I tried so far had problems with x2APIC mode on
(given APIC IDs < 255) and IRQ remapping disabled.
> from Intel felt that it should not be allowed to create a kernel that
> can run on real HW and has non architectural configuration compiled in,
> though only when running on a VM x2apic will ever be enabled without irq
> remapping. I didn't argue about it to much back then. If HYPERVISOR_GUEST
> guaranties that resulting kernel can run only on a VM (does it?) this
> objection does not hold any more.
Yes, indeed. Your patch suggested to remove the dependency, this one
preserves it. There will still be no real hardware able to turn on
x2APIC without IRQ remapping enabled as well (though I'm hoping to
overcome this for Jailhouse scenarios until we can hand over DMAR units
from Linux to the hypervisor).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2014-07-06 15:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-05 7:47 [PATCH] x86: Make x2APIC support depend on interrupt remapping or guest support Jan Kiszka
2014-07-06 14:32 ` Paolo Bonzini
2014-07-06 15:12 ` Gleb Natapov
2014-07-06 15:24 ` Jan Kiszka
2014-07-06 15:41 ` Gleb Natapov
2014-07-06 15:49 ` Jan Kiszka [this message]
2014-07-06 17:28 ` Gleb Natapov
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=53B96FF5.2050107@web.de \
--to=jan.kiszka@web.de \
--cc=gleb@kernel.org \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).