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: Keir Fraser <keir.xen@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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 23 Aug 2011 15:47:02 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 23 Aug 2011 00:49:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA791608.1FA13%keir.xen@xxxxxxxxx>
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>
References: <749B9D3DBF0F054390025D9EAFF47F2212D123FF52@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CA791608.1FA13%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acxg1o39NltmdPMdRwe+6OdPuDvibwAaSKsQAAnEsMYAADM7kA==
Thread-topic: [PATCH] Fix xen hang on intel westmere-EP
> 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...)

Thanks
Kevin

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