Suresh Siddha writes:
> On Wed, 2009-07-01 at 17:17 -0700, Eric W. Biederman wrote:
>> Suresh Siddha writes:
>> > Among number of experiments you have tried in the past to fix this, have
>> > you tried the experiment of explicitly clearing the remoteIRR by
>> > changing the trigger mode to edge
On Wed, 2009-07-01 at 17:17 -0700, Eric W. Biederman wrote:
> Suresh Siddha writes:
> > Among number of experiments you have tried in the past to fix this, have
> > you tried the experiment of explicitly clearing the remoteIRR by
> > changing the trigger mode to edge and then back to level.
> >
>
Suresh Siddha writes:
> On Tue, 2009-06-30 at 12:36 -0700, Eric W. Biederman wrote:
>> Dropped irqs.. Driver hangs because it is waiting for an irq. Hardware
>> hangs because it is waiting for the cpu to process the irq.
>>
>> Potentially we get a level triggered irq that is never acked by
>>
On Tue, 2009-06-30 at 12:36 -0700, Eric W. Biederman wrote:
> Dropped irqs.. Driver hangs because it is waiting for an irq. Hardware
> hangs because it is waiting for the cpu to process the irq.
>
> Potentially we get a level triggered irq that is never acked by
> the cpu that won't arm until th
Avi Kivity writes:
> On 06/30/2009 10:36 PM, Eric W. Biederman wrote:
The short version is I don't know what work arounds we will ultimately
decide to deploy to work with real hardware.
I have been seriously contemplating causing a cpu hot-unplug request
to fail if we are
On 06/30/2009 10:36 PM, Eric W. Biederman wrote:
The short version is I don't know what work arounds we will ultimately
decide to deploy to work with real hardware.
I have been seriously contemplating causing a cpu hot-unplug request
to fail if we are in ioapic mode and we have irqs routed to th
Gleb Natapov writes:
> Considering that interrupt remapping is fairly new feature
> are you saying that hotplug (pci and cpu) on x86 is a horrible
> hack on Linux?
Just the current cpu hotplug path.
>> It is better than nothing but it certainly is not something
>> I would expect to work all of
Avi Kivity writes:
> On 06/30/2009 10:08 PM, Eric W. Biederman wrote:
>>> Can you elaborate? For kvm guests, the hardware is reasonably will
>>> implemented
>>> and if not we will fix it. We need not cripple a feature just because some
>>> hardware is broken.
>>>
>>
>> The short version
On 06/30/2009 10:08 PM, Eric W. Biederman wrote:
Can you elaborate? For kvm guests, the hardware is reasonably will implemented
and if not we will fix it. We need not cripple a feature just because some
hardware is broken.
The short version is I don't know what work arounds we will ulti
Avi Kivity writes:
> On 06/30/2009 07:44 PM, Eric W. Biederman wrote:
To support that seriously you need interrupt remapping.
>>> Can you explain why?
>>>
>>
>> Because ioapics don't fully function according to spec,
>> and the interrupt code on the hotplug path is a
On Tue, Jun 30, 2009 at 09:44:54AM -0700, Eric W. Biederman wrote:
> Gleb Natapov writes:
>
> > On Tue, Jun 30, 2009 at 02:24:05AM -0700, Eric W. Biederman wrote:
> >> Gleb Natapov writes:
> >>
> >> > KVM would like to provide x2APIC interface to a guest without emulating
> >> > interrupt remap
On 06/30/2009 07:44 PM, Eric W. Biederman wrote:
To support that seriously you need interrupt remapping.
Can you explain why?
Because ioapics don't fully function according to spec,
and the interrupt code on the hotplug path is a horrible
terrible broken hack for ioapics.
It is
Gleb Natapov writes:
> On Tue, Jun 30, 2009 at 02:24:05AM -0700, Eric W. Biederman wrote:
>> Gleb Natapov writes:
>>
>> > KVM would like to provide x2APIC interface to a guest without emulating
>> > interrupt remapping device. The reason KVM prefers guest to use x2APIC
>> > is that x2APIC inter
On Tue, Jun 30, 2009 at 02:24:05AM -0700, Eric W. Biederman wrote:
> Gleb Natapov writes:
>
> > KVM would like to provide x2APIC interface to a guest without emulating
> > interrupt remapping device. The reason KVM prefers guest to use x2APIC
> > is that x2APIC interface is better virtualizable a
Gleb Natapov writes:
> KVM would like to provide x2APIC interface to a guest without emulating
> interrupt remapping device. The reason KVM prefers guest to use x2APIC
> is that x2APIC interface is better virtualizable and provides better
> performance than mmio xAPIC interface:
>
> - msr exits a
On Mon, Jun 29, 2009 at 08:15:05AM -0700, Suresh Siddha wrote:
> On Mon, 2009-06-29 at 08:10 -0700, Gleb Natapov wrote:
> > On Mon, Jun 29, 2009 at 07:58:39AM -0700, Suresh Siddha wrote:
> > > Thinking more, probably we shouldn't remove this dependency. This might
> > > encourage people (knowingly
On Mon, 2009-06-29 at 08:10 -0700, Gleb Natapov wrote:
> On Mon, Jun 29, 2009 at 07:58:39AM -0700, Suresh Siddha wrote:
> > Thinking more, probably we shouldn't remove this dependency. This might
> > encourage people (knowingly or unknowingly) to enable x2apic without
> > interrupt-remapping. Can w
On Mon, Jun 29, 2009 at 07:58:39AM -0700, Suresh Siddha wrote:
> On Mon, 2009-06-29 at 06:29 -0700, Gleb Natapov wrote:
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index d1430ef..3e5b6ea 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -260,12 +260,15 @@ config SMP
>
On Mon, 2009-06-29 at 06:29 -0700, Gleb Natapov wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index d1430ef..3e5b6ea 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -260,12 +260,15 @@ config SMP
>
> config X86_X2APIC
> bool "Support x2apic"
> - depends on X8
19 matches
Mail list logo
