From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754736AbZFTI55 (ORCPT ); Sat, 20 Jun 2009 04:57:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751271AbZFTI5s (ORCPT ); Sat, 20 Jun 2009 04:57:48 -0400 Received: from mga03.intel.com ([143.182.124.21]:48977 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbZFTI5r (ORCPT ); Sat, 20 Jun 2009 04:57:47 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.42,258,1243839600"; d="scan'208";a="156682633" From: "Tian, Kevin" To: "Eric W. Biederman" , Keir Fraser CC: Jeremy Fitzhardinge , Xen-devel , the arch/x86 maintainers , Linux Kernel Mailing List , Ingo Molnar , "Nakajima, Jun" , "H. Peter Anvin" , Thomas Gleixner , Len Brown Date: Sat, 20 Jun 2009 16:57:43 +0800 Subject: RE: [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Thread-Topic: [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Thread-Index: AcnxgECFuUm7zR6rT+uZmFUuvQQfLgAAHqXw Message-ID: <0A882F4D99BBF6449D58E61AAFD7EDD62F1B68F3@pdsmsx502.ccr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by alpha.home.local id n5K8wl54029520 >From: Eric W. Biederman >Sent: 2009620 16:22 > >Keir Fraser writes: > >> On 20/06/2009 00:44, "Nakajima, Jun" wrote: >> >>>> 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. >> >> Yes, we could reconsider. However is there any stuff that >dom0 remains >> responsible for (e.g., PCI management, and therefore PCI >hotplug) where it >> would continue to need to be OSPM, interpreting certain AML >objects? In >> general how safe would it be to have two layered entities >both playing at >> being OSPM? > >Short of running the oddball acpi based drivers. I'm not familiar with >any acpi in the pci management. > PCIe hotplug is defined well by its own BUS spec. But conventional PCI hotplug is implemented all kinds of strange things. Some is through ACPI, and thus by moving ACPI into Xen, a new 'virtual' hotplug architecture has to be introduced into dom0 Linux. Or Xen needs to emulate some known interface but as said there's no common standard for PCI hotplug. What's worse is the docking station support which contains diverse legacy devices. How Xen pass those legacy device hotplug events into dom0 Linux become another gray area suffering from same question like whether IOAPIC needs to be changed for Xen... Above comes from the exclusive assumption that ACPI is removed from dom0 by moving into Xen. Another choice is to have two layered ACPI in both dom0 and Xen with dom0's ACPI virtualized a bit by Xen. However it's messy as ACPI encodes most stuff in its own AML encode as a gray box. Many ACPI methods talk to hardware bits internally even by hard coded I/O registers. You don't know whether one ACPI event should be handled by Xen or not, until some AML methods have been evaluated which then may already consume and change some device states and not reversible. Then Xen have to emulate those states when injecting a virtual ACPI event into dom0 as dom0 ACPI methods need to consume same states. However automatic generating emulation code for diverse ACPI implementations to me is far more complex than any discussion here. So the real trouble is ACPI , which encode all platform bits if they're not included in any existing BUS spec, such as power, thermal, processor, battery, PCI routing, hotplug, EC, etc. Some are owned by dom0 and some by Xen. However ACPI's AML encoding makes automatic division between two categories really difficult. Thanks, Kevin{.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tian, Kevin" 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 16:57:43 +0800 Message-ID: <0A882F4D99BBF6449D58E61AAFD7EDD62F1B68F3@pdsmsx502.ccr.corp.intel.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0377785274==" Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Eric W. Biederman" , Keir Fraser Cc: Jeremy Fitzhardinge , Xen-devel , the arch/x86 maintainers , Linux Kernel Mailing List , Ingo Molnar , "Nakajima, Jun" , "H. Peter Anvin" , Thomas Gleixner , Len Brown List-Id: xen-devel@lists.xenproject.org --===============0377785274== Content-Language: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 PkZyb206IEVyaWMgVy4gQmllZGVybWFuDQo+U2VudDogMjAwOcTqNtTCMjDI1SAxNjoyMg0KPg0K PktlaXIgRnJhc2VyIDxrZWlyLmZyYXNlckBldS5jaXRyaXguY29tPiB3cml0ZXM6DQo+DQo+PiBP biAyMC8wNi8yMDA5IDAwOjQ0LCAiTmFrYWppbWEsIEp1biIgPGp1bi5uYWthamltYUBpbnRlbC5j b20+IHdyb3RlOg0KPj4NCj4+Pj4gSSBhc3N1bWUgdGhhdCBwdXR0aW5nIEFNTCBpbnRvIFhlbiBo YXMgYmVlbiBjb25zaWRlcmVkLCBidXQgSSBkb24ndA0KPj4+PiBhbnl0aGluZyBhYm91dCB0aG9z ZSBkZWxpYmVyYXRpb25zLiAgS2Vpcj8gSnVuPw0KPj4+PiANCj4+PiANCj4+PiBZZXMsIGl0IHdh cyBvbmUgb2YgdGhlIG9wdGlvbnMgeWVhcnMgYWdvLiBXZSBkaWQgbm90IGRvIA0KPnRoYXQgYmVj YXVzZSBMaW51eCBhbmQNCj4+PiBTb2xhcmlzIChhcyBkb20wKSBhbHJlYWR5IGhhZCB0aGUgQU1M IGludGVycHJldGVyIGFuZCBpdCdzIA0KPm92ZXJraWxsIGFuZA0KPj4+IHJlZHVuZGFudCB0byBo YXZlIHN1Y2ggYSBsYXJnZSBjb21wb25lbnQgaW4gdGhlIFhlbiANCj5oeXBlcnZpc29yLiBTaW5j ZSB0aGUNCj4+PiBoeXBlcnZpc29yIGRvZXMgbW9zdCBvZiB0aGUgcG93ZXIgbWFuYWdlbWVudCAo aS5lLiBQLCBDLCANCj5TLXN0YXRlLCBldGMuKQ0KPj4+IGdldHRpbmcgdGhlIGluZm8gZnJvbSBk b20wIHRvZGF5LCB3ZSBtaWdodCB3YW50IHRvIA0KPnJlY29uc2lkZXIgdGhlIG9wdGlvbi4NCj4+ DQo+PiBZZXMsIHdlIGNvdWxkIHJlY29uc2lkZXIuIEhvd2V2ZXIgaXMgdGhlcmUgYW55IHN0dWZm IHRoYXQgDQo+ZG9tMCByZW1haW5zDQo+PiByZXNwb25zaWJsZSBmb3IgKGUuZy4sIFBDSSBtYW5h Z2VtZW50LCBhbmQgdGhlcmVmb3JlIFBDSSANCj5ob3RwbHVnKSB3aGVyZSBpdA0KPj4gd291bGQg Y29udGludWUgdG8gbmVlZCB0byBiZSBPU1BNLCBpbnRlcnByZXRpbmcgY2VydGFpbiBBTUwgDQo+ b2JqZWN0cz8gSW4NCj4+IGdlbmVyYWwgaG93IHNhZmUgd291bGQgaXQgYmUgdG8gaGF2ZSB0d28g bGF5ZXJlZCBlbnRpdGllcyANCj5ib3RoIHBsYXlpbmcgYXQNCj4+IGJlaW5nIE9TUE0/DQo+DQo+ U2hvcnQgb2YgcnVubmluZyB0aGUgb2RkYmFsbCBhY3BpIGJhc2VkIGRyaXZlcnMuICBJJ20gbm90 IGZhbWlsaWFyIHdpdGgNCj5hbnkgYWNwaSBpbiB0aGUgcGNpIG1hbmFnZW1lbnQuDQo+DQoNClBD SWUgaG90cGx1ZyBpcyBkZWZpbmVkIHdlbGwgYnkgaXRzIG93biBCVVMgc3BlYy4gQnV0IGNvbnZl bnRpb25hbA0KUENJIGhvdHBsdWcgaXMgaW1wbGVtZW50ZWQgYWxsIGtpbmRzIG9mIHN0cmFuZ2Ug dGhpbmdzLiBTb21lIGlzDQp0aHJvdWdoIEFDUEksIGFuZCB0aHVzIGJ5IG1vdmluZyBBQ1BJIGlu dG8gWGVuLCBhIG5ldyAndmlydHVhbCcgaG90cGx1Zw0KYXJjaGl0ZWN0dXJlIGhhcyB0byBiZSBp bnRyb2R1Y2VkIGludG8gZG9tMCBMaW51eC4gT3IgWGVuIG5lZWRzIHRvIA0KZW11bGF0ZSBzb21l IGtub3duIGludGVyZmFjZSBidXQgYXMgc2FpZCB0aGVyZSdzIG5vIGNvbW1vbiBzdGFuZGFyZA0K Zm9yIFBDSSBob3RwbHVnLiBXaGF0J3Mgd29yc2UgaXMgdGhlIGRvY2tpbmcgc3RhdGlvbiBzdXBw b3J0IHdoaWNoIA0KY29udGFpbnMgZGl2ZXJzZSBsZWdhY3kgZGV2aWNlcy4gSG93IFhlbiBwYXNz IHRob3NlIGxlZ2FjeSBkZXZpY2UgDQpob3RwbHVnIGV2ZW50cyBpbnRvIGRvbTAgTGludXggYmVj b21lIGFub3RoZXIgZ3JheSBhcmVhIHN1ZmZlcmluZyBmcm9tIA0Kc2FtZSBxdWVzdGlvbiBsaWtl IHdoZXRoZXIgSU9BUElDIG5lZWRzIHRvIGJlIGNoYW5nZWQgZm9yIFhlbi4uLg0KDQpBYm92ZSBj b21lcyBmcm9tIHRoZSBleGNsdXNpdmUgYXNzdW1wdGlvbiB0aGF0IEFDUEkgaXMgcmVtb3ZlZA0K ZnJvbSBkb20wIGJ5IG1vdmluZyBpbnRvIFhlbi4NCg0KQW5vdGhlciBjaG9pY2UgaXMgdG8gaGF2 ZSB0d28gbGF5ZXJlZCBBQ1BJIGluIGJvdGggZG9tMCBhbmQgWGVuDQp3aXRoIGRvbTAncyBBQ1BJ IHZpcnR1YWxpemVkIGEgYml0IGJ5IFhlbi4gSG93ZXZlciBpdCdzIG1lc3N5IGFzIA0KQUNQSSBl bmNvZGVzIG1vc3Qgc3R1ZmYgaW4gaXRzIG93biBBTUwgZW5jb2RlIGFzIGEgZ3JheSBib3guIA0K TWFueSBBQ1BJIG1ldGhvZHMgdGFsayB0byBoYXJkd2FyZSBiaXRzIGludGVybmFsbHkgZXZlbiBi eSBoYXJkIA0KY29kZWQgSS9PIHJlZ2lzdGVycy4gWW91IGRvbid0IGtub3cgd2hldGhlciBvbmUg QUNQSSBldmVudCANCnNob3VsZCBiZSBoYW5kbGVkIGJ5IFhlbiBvciBub3QsIHVudGlsIHNvbWUg QU1MIG1ldGhvZHMgaGF2ZSANCmJlZW4gZXZhbHVhdGVkIHdoaWNoIHRoZW4gbWF5IGFscmVhZHkg Y29uc3VtZSBhbmQgY2hhbmdlIA0Kc29tZSBkZXZpY2Ugc3RhdGVzIGFuZCBub3QgcmV2ZXJzaWJs ZS4gVGhlbiBYZW4gaGF2ZSB0byBlbXVsYXRlIA0KdGhvc2Ugc3RhdGVzIHdoZW4gaW5qZWN0aW5n IGEgdmlydHVhbCBBQ1BJIGV2ZW50IGludG8gZG9tMCBhcyANCmRvbTAgQUNQSSBtZXRob2RzIG5l ZWQgdG8gY29uc3VtZSBzYW1lIHN0YXRlcy4gSG93ZXZlcg0KYXV0b21hdGljIGdlbmVyYXRpbmcg ZW11bGF0aW9uIGNvZGUgZm9yIGRpdmVyc2UgQUNQSSBpbXBsZW1lbnRhdGlvbnMNCnRvIG1lIGlz IGZhciBtb3JlIGNvbXBsZXggdGhhbiBhbnkgZGlzY3Vzc2lvbiBoZXJlLiANCg0KU28gdGhlIHJl YWwgdHJvdWJsZSBpcyBBQ1BJICwgd2hpY2ggZW5jb2RlIGFsbCBwbGF0Zm9ybSBiaXRzIGlmIA0K dGhleSdyZSBub3QgaW5jbHVkZWQgaW4gYW55IGV4aXN0aW5nIEJVUyBzcGVjLCBzdWNoIGFzIHBv d2VyLCANCnRoZXJtYWwsIHByb2Nlc3NvciwgYmF0dGVyeSwgUENJIHJvdXRpbmcsIGhvdHBsdWcs IEVDLCBldGMuIFNvbWUNCmFyZSBvd25lZCBieSBkb20wIGFuZCBzb21lIGJ5IFhlbi4gSG93ZXZl ciBBQ1BJJ3MgQU1MIGVuY29kaW5nDQptYWtlcyBhdXRvbWF0aWMgZGl2aXNpb24gYmV0d2VlbiB0 d28gY2F0ZWdvcmllcyByZWFsbHkgZGlmZmljdWx0Lg0KDQpUaGFua3MsDQpLZXZpbg== --===============0377785274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0377785274==--