WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH] Fix xen hang on intel westmere-EP

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Fix xen hang on intel westmere-EP
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Tue, 23 Aug 2011 09:04:49 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 23 Aug 2011 01:07:22 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=JyfOUU/CuEvaBo9l5uERhPFPKBjP67b54Ebzgh5bc0g=; b=VE5lmuZGRk02m69fTVxcjs4TDpA4K5rvAf64JdspABNpc/BQIkSbBf+wF4xTnKaVLN vsRSatyXPuezbOtzGso8aUXiZI9Pt1OZfp6k90s10SAWQK66AGMK2FNSZuEPZn44THki JK8h0YsIxiCs4JiMhqDksiYfU8+UmiYhBwVt8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <625BA99ED14B2D499DC4E29D8138F150630051F1BD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acxg1o39NltmdPMdRwe+6OdPuDvibwAaSKsQAAnEsMYAADM7kAAA8Ptg
Thread-topic: [PATCH] Fix xen hang on intel westmere-EP
User-agent: Microsoft-Entourage/12.30.0.110427
On 23/08/2011 08:47, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

>> From: Keir Fraser
>> Sent: Tuesday, August 23, 2011 3:32 PM
>> 
>> On 23/08/2011 04:52, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
>> 
>>>> Further I'm opposed to introducing further instances of legacy brute- force
>>>> PCI
>>>> bus scans.
>>>> 
>>>> And I don't think you got something along these lines accepted into Linux,
>>>> did
>>>> you? It ought to be DMI based there, too.
>>> I don't know why you think using DMI is a better way? For BDF based way, we
>>> only need to know the device ID. But for DMI base way, I don't know which
>>> condition should be matched.
>>> 
>>> Actually, the best way to solve it is to enable the ACPI mode in Xen instead
>>> of in dom0. For enable ACPI, we need to write the value from
>> FADT.ACPI_ENABLE
>>> to SMI_CMD. After writing the value, the SMI ownership will be disable by
>> ACPI
>>> hardware and it also will disable some logic which is able to cause SMI. For
>>> example, the legacy USB circuit will be masked too. Because at this point,
>>> there have no need to use legacy usb emulation. This is also what linux
>>> upstream did. But I think it is too complicated to port this logic to xen.
>>> Anyway, if you have interesting, you can add this logic to xen and there
>>> have
>>> no need for this patch again.
>> 
>> It sounds like quite a good idea, and not very complicated at all. The main
>> concern would be potential other fall out from making the change.
>> 
> 
> This is indeed tricky though. This ACPI mode enable basically tells that Xen
> is
> ready to own ACPI hardware registers through ACPI SCI mode, instead of
> legacy SMI mode. However SCI itself requires some encoded ACPI information,
> such as routing and overlapping info, which depends on dom0. So Xen is not
> ready to handle SCI before dom0 boots.
> 
> On the other hand, Linux does this ACPI mode enable late until APs are
> ready to boot. Before that point there're some extra preparations completed
> already, such as DMI system check (which may disable ACPI), root namespace
> initialization, etc. I'm not sure whether those extra preparations can be all
> moved down to Xen (some of them access encoded content), or can be safely
> skipped in Xen (e.g. DMI check...)

That's a bit of a shame. Yes, sounds like quite a lot of pain.

 -- Keir

> Thanks
> Kevin



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel