From: Avi Kivity <avi@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Gleb Natapov <gleb@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Suresh Siddha <suresh.b.siddha@intel.com>,
Sheng Yang <sheng@linux.intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH v3] enable x2APIC without interrupt remapping under KVM
Date: Tue, 30 Jun 2009 22:16:41 +0300 [thread overview]
Message-ID: <4A4A6499.9000406@redhat.com> (raw)
In-Reply-To: <m1ljn94k16.fsf@fess.ebiederm.org>
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 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 the cpu
> that is being unplugged.
>
Well, obviously we need to disassociate any irqs from such a cpu. Could
be done from the kernel or only enforced by the kernel.
> Even with perfectly working hardware it is not possible in the general
> case to migrate an ioapic irq from one cpu to another outside of an
> interrupt handler without without risking dropping an interrupt.
>
Can't you generate a spurious interrupt immediately after the
migration? An extra interrupt shouldn't hurt.
> There is no general way to know you have seen the last interrupt
> floating around your system. PCI ordering rules don't help because
> the ioapics can potentially take an out of band channel.
>
Can you describe the problem scenario? an ioapic->lapic message
delivered to a dead cpu?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
next prev parent reply other threads:[~2009-06-30 19:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-29 13:29 [PATCH v3] enable x2APIC without interrupt remapping under KVM Gleb Natapov
2009-06-29 14:58 ` Suresh Siddha
2009-06-29 15:10 ` Gleb Natapov
2009-06-29 15:15 ` Suresh Siddha
2009-06-29 15:45 ` Gleb Natapov
2009-06-30 9:24 ` Eric W. Biederman
2009-06-30 9:26 ` Gleb Natapov
2009-06-30 16:44 ` Eric W. Biederman
2009-06-30 17:12 ` Avi Kivity
2009-06-30 19:08 ` Eric W. Biederman
2009-06-30 19:16 ` Avi Kivity [this message]
2009-06-30 19:36 ` Eric W. Biederman
2009-07-01 8:30 ` Avi Kivity
2009-07-01 13:31 ` Eric W. Biederman
2009-07-01 22:53 ` Suresh Siddha
2009-07-02 0:17 ` Eric W. Biederman
2009-07-07 16:14 ` Suresh Siddha
2009-07-10 20:29 ` Eric W. Biederman
2009-06-30 19:03 ` Gleb Natapov
2009-06-30 19:43 ` Eric W. Biederman
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=4A4A6499.9000406@redhat.com \
--to=avi@redhat.com \
--cc=ebiederm@xmission.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sheng@linux.intel.com \
--cc=suresh.b.siddha@intel.com \
/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.