All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Nakajima\, Jun" <jun.nakajima@intel.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen-devel <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org>
Subject: Re: [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC
Date: Sat, 20 Jun 2009 01:18:07 -0700	[thread overview]
Message-ID: <m163erpbcw.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <0B53E02A2965CE4F9ADB38B34501A3A188656507@orsmsx505.amr.corp.intel.com> (Jun Nakajima's message of "Fri\, 19 Jun 2009 16\:44\:24 -0700")

"Nakajima, Jun" <jun.nakajima@intel.com> writes:

> Jeremy Fitzhardinge wrote on Fri, 19 Jun 2009 at 12:58:14:
>
>>> 
>>> Which if dom0 is to be redundant/restartable seems to make the
>>> argument for AML living in Xen.
>>> 
>>> Xen has everything except the AML interpreter.
>>> 
>> 
>> I assume that putting AML into Xen has been considered, but I don't
>> anything about those deliberations.  Keir? Jun?
>> 
>
> Yes, it was one of the options years ago. We did not do that because Linux and Solaris (as dom0) already had the AML interpreter and it's overkill and redundant to have such a large component in the Xen hypervisor. Since the hypervisor does most of the power management (i.e. P, C, S-state, etc.) getting the info from dom0 today, we might want to reconsider the option. 

In my brief investigation it looks as if Xen having the AML
interpreter would considerably simplify the complexity of the
dom0 interface.

What I am certain of is that the current Xen dom0 irq interface exposes
implementation details (aka the vector number) that if continued will prevent
Xen from scaling to machines with large amounts of I/O.  As YH has recently
demonstrated.

That interface needs to be fixed.

I think the path to fixing it and getting linux kernel support is.
- Merge pass through device support for domU.
- Move all of the irq setup from dom0 into Xen, making dom0 interrupt
  handling exactly the same as domU.
- Move all of ACPI handling into Xen, in support of irq handling
  and power management.  Things Xen already claims are interesting
  problems.

At that point I don't know what is left but in the area that I am
knowledge, irq handling, will be complete.  The incestuousness of
the interface is removed and Xen and the linux kernel can keep those
same interfaces for the foreseeable future.

In summary.  

In support of the Xen grand vision of all domains being equal.  I
don't think linux should ever merge dom0 support.  I think domU
support should be expanded, and the dom0 requirements simplified
until there are no differences left.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Nakajima, Jun" <jun.nakajima@intel.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen-devel <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org>
Subject: Re: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC
Date: Sat, 20 Jun 2009 01:18:07 -0700	[thread overview]
Message-ID: <m163erpbcw.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <0B53E02A2965CE4F9ADB38B34501A3A188656507@orsmsx505.amr.corp.intel.com> (Jun Nakajima's message of "Fri\, 19 Jun 2009 16\:44\:24 -0700")

"Nakajima, Jun" <jun.nakajima@intel.com> writes:

> Jeremy Fitzhardinge wrote on Fri, 19 Jun 2009 at 12:58:14:
>
>>> 
>>> Which if dom0 is to be redundant/restartable seems to make the
>>> argument for AML living in Xen.
>>> 
>>> Xen has everything except the AML interpreter.
>>> 
>> 
>> I assume that putting AML into Xen has been considered, but I don't
>> anything about those deliberations.  Keir? Jun?
>> 
>
> Yes, it was one of the options years ago. We did not do that because Linux and Solaris (as dom0) already had the AML interpreter and it's overkill and redundant to have such a large component in the Xen hypervisor. Since the hypervisor does most of the power management (i.e. P, C, S-state, etc.) getting the info from dom0 today, we might want to reconsider the option. 

In my brief investigation it looks as if Xen having the AML
interpreter would considerably simplify the complexity of the
dom0 interface.

What I am certain of is that the current Xen dom0 irq interface exposes
implementation details (aka the vector number) that if continued will prevent
Xen from scaling to machines with large amounts of I/O.  As YH has recently
demonstrated.

That interface needs to be fixed.

I think the path to fixing it and getting linux kernel support is.
- Merge pass through device support for domU.
- Move all of the irq setup from dom0 into Xen, making dom0 interrupt
  handling exactly the same as domU.
- Move all of ACPI handling into Xen, in support of irq handling
  and power management.  Things Xen already claims are interesting
  problems.

At that point I don't know what is left but in the area that I am
knowledge, irq handling, will be complete.  The incestuousness of
the interface is removed and Xen and the linux kernel can keep those
same interfaces for the foreseeable future.

In summary.  

In support of the Xen grand vision of all domains being equal.  I
don't think linux should ever merge dom0 support.  I think domU
support should be expanded, and the dom0 requirements simplified
until there are no differences left.

Eric

  parent reply	other threads:[~2009-06-20  8:18 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-12 18:22 [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Jeremy Fitzhardinge
2009-06-12 18:22 ` Jeremy Fitzhardinge
2009-06-12 18:28 ` Alan Cox
2009-06-12 18:28   ` Alan Cox
2009-06-12 18:33   ` Jeremy Fitzhardinge
2009-06-12 18:33     ` Jeremy Fitzhardinge
2009-06-12 20:11 ` Cyrill Gorcunov
2009-06-15  2:01   ` Jeremy Fitzhardinge
2009-06-12 20:35 ` Eric W. Biederman
2009-06-12 20:35   ` Eric W. Biederman
2009-06-15  2:06   ` Jeremy Fitzhardinge
2009-06-15 10:47     ` Eric W. Biederman
2009-06-15 10:47       ` Eric W. Biederman
2009-06-15 20:49       ` Jeremy Fitzhardinge
2009-06-15 20:49         ` Jeremy Fitzhardinge
2009-06-15 21:58         ` Eric W. Biederman
2009-06-15 21:58           ` Eric W. Biederman
2009-06-16 19:38           ` Jeremy Fitzhardinge
2009-06-16 19:38             ` Jeremy Fitzhardinge
2009-06-17  5:10             ` Eric W. Biederman
2009-06-17  5:10               ` Eric W. Biederman
2009-06-17 12:02             ` Eric W. Biederman
2009-06-17 12:02               ` Eric W. Biederman
2009-06-17 17:32               ` Jeremy Fitzhardinge
2009-06-17 17:32                 ` Jeremy Fitzhardinge
2009-06-18  2:58                 ` Eric W. Biederman
2009-06-18  2:58                   ` Eric W. Biederman
2009-06-18 19:34                   ` Jeremy Fitzhardinge
2009-06-18 19:34                     ` Jeremy Fitzhardinge
2009-06-18 20:28                     ` Eric W. Biederman
2009-06-18 21:09                       ` Jeremy Fitzhardinge
2009-06-18 21:09                         ` Jeremy Fitzhardinge
2009-06-19  1:38                         ` Eric W. Biederman
2009-06-19  1:38                           ` Eric W. Biederman
2009-06-19  3:10                           ` [Xen-devel] " Jiang, Yunhong
2009-06-19  3:10                             ` Jiang, Yunhong
2009-06-18 12:26                 ` Eric W. Biederman
2009-06-15 10:51 ` Eric W. Biederman
2009-06-15 10:51   ` Eric W. Biederman
2009-06-18 16:08 ` Len Brown
2009-06-18 19:14   ` Jeremy Fitzhardinge
2009-06-18 19:14     ` Jeremy Fitzhardinge
2009-06-18 19:27     ` Eric W. Biederman
2009-06-18 19:48       ` Jeremy Fitzhardinge
2009-06-18 19:48         ` Jeremy Fitzhardinge
2009-06-18 20:39         ` Eric W. Biederman
2009-06-18 22:33           ` Jeremy Fitzhardinge
2009-06-18 22:33             ` Jeremy Fitzhardinge
2009-06-19  2:42             ` Eric W. Biederman
2009-06-19  2:42               ` Eric W. Biederman
2009-06-19 19:58               ` Jeremy Fitzhardinge
2009-06-19 19:58                 ` Jeremy Fitzhardinge
2009-06-19 23:44                 ` [Xen-devel] " Nakajima, Jun
2009-06-19 23:44                   ` Nakajima, Jun
2009-06-20  7:39                   ` [Xen-devel] " Keir Fraser
2009-06-20  7:39                     ` Keir Fraser
2009-06-20  8:21                     ` [Xen-devel] " Eric W. Biederman
2009-06-20  8:21                       ` Eric W. Biederman
2009-06-20  8:57                       ` [Xen-devel] " Tian, Kevin
2009-06-20  8:57                         ` Tian, Kevin
2009-06-20 10:22                         ` [Xen-devel] " Keir Fraser
2009-06-20 10:22                           ` Keir Fraser
2009-06-20  8:18                   ` Eric W. Biederman [this message]
2009-06-20  8:18                     ` Eric W. Biederman
2009-06-19  5:32             ` Yinghai Lu
2009-06-19  5:32               ` Yinghai Lu
2009-06-19  5:50               ` Eric W. Biederman
2009-06-19  5:50                 ` Eric W. Biederman
2009-06-19  7:52               ` [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs justbecause " Jan Beulich
2009-06-19  7:52                 ` Jan Beulich
2009-06-19  8:16                 ` [Xen-devel] " Eric W. Biederman
2009-06-19  8:16                   ` Eric W. Biederman
2009-06-20  3:58                   ` [Xen-devel] " Yinghai Lu
2009-06-20  3:58                     ` Yinghai Lu
2009-06-20  5:40                     ` [Xen-devel] " Eric W. Biederman
2009-06-20  5:40                       ` Eric W. Biederman
2009-06-20  5:58                       ` [Xen-devel] " Yinghai Lu
2009-06-20  5:58                         ` Yinghai Lu
2009-06-18 22:51     ` [PATCH RFC] x86/acpi: don't ignore I/O APICs just because " Maciej W. Rozycki

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=m163erpbcw.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=jun.nakajima@intel.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.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.