From: Jan Kiszka <[email protected]>
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.
Signed-off-by: Jan Kiszka <[email protected]>
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a8f749e..30a9987 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -310,7 +310,7 @@ config SMP
config X86_X2APIC
bool "Support x2apic"
- depends on X86_LOCAL_APIC && X86_64 && IRQ_REMAP
+ depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
---help---
This enables x2apic support on CPUs that have this feature.
Il 05/07/2014 09:47, Jan Kiszka ha scritto:
> From: Jan Kiszka <[email protected]>
>
> 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.
>
> Signed-off-by: Jan Kiszka <[email protected]>
> ---
> arch/x86/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index a8f749e..30a9987 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -310,7 +310,7 @@ config SMP
>
> config X86_X2APIC
> bool "Support x2apic"
> - depends on X86_LOCAL_APIC && X86_64 && IRQ_REMAP
> + depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
> ---help---
> This enables x2apic support on CPUs that have this feature.
>
>
>
Makes sense.
Acked-by: Paolo Bonzini <[email protected]>
On Sat, Jul 05, 2014 at 09:47:54AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka <[email protected]>
>
> 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.
>
> Signed-off-by: Jan Kiszka <[email protected]>
> ---
> arch/x86/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index a8f749e..30a9987 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -310,7 +310,7 @@ config SMP
>
> config X86_X2APIC
> bool "Support x2apic"
> - depends on X86_LOCAL_APIC && X86_64 && IRQ_REMAP
> + depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
> ---help---
> This enables x2apic support on CPUs that have this feature.
>
>
>
--
Gleb.
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 <[email protected]>
>>
>> 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.
However, this change is just formalizing a configuration that is already
being used: there is no interrupt remapping available with KVM (yet),
but we do run our guests in x2APIC mode most of the time. Interrupt
remapping code in kernels tailored as KVM guest is dead code, right now.
Jan
>
>>
>> Signed-off-by: Jan Kiszka <[email protected]>
>> ---
>> arch/x86/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index a8f749e..30a9987 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -310,7 +310,7 @@ config SMP
>>
>> config X86_X2APIC
>> bool "Support x2apic"
>> - depends on X86_LOCAL_APIC && X86_64 && IRQ_REMAP
>> + depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
>> ---help---
>> This enables x2apic support on CPUs that have this feature.
>>
>>
>>
>
>
>
> --
> Gleb.
>
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 <[email protected]>
> >>
> >> 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
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.
>
> However, this change is just formalizing a configuration that is already
> being used: there is no interrupt remapping available with KVM (yet),
> but we do run our guests in x2APIC mode most of the time. Interrupt
> remapping code in kernels tailored as KVM guest is dead code, right now.
Yes. I am just saying why things are the way they are.
>
> Jan
>
> >
> >>
> >> Signed-off-by: Jan Kiszka <[email protected]>
> >> ---
> >> arch/x86/Kconfig | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index a8f749e..30a9987 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -310,7 +310,7 @@ config SMP
> >>
> >> config X86_X2APIC
> >> bool "Support x2apic"
> >> - depends on X86_LOCAL_APIC && X86_64 && IRQ_REMAP
> >> + depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
> >> ---help---
> >> This enables x2apic support on CPUs that have this feature.
> >>
> >>
> >>
> >
> >
> >
> > --
> > Gleb.
> >
>
>
--
Gleb.
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 <[email protected]>
>>>>
>>>> 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
On Sun, Jul 06, 2014 at 05:49:09PM +0200, Jan Kiszka wrote:
> 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 <[email protected]>
> >>>>
> >>>> 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.
Not sure I saw that written, but I was told many times that this is so.
--
Gleb.