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: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] Fix xen hang on intel westmere-EP
From: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>
Date: Tue, 23 Aug 2011 11:52:39 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Keir, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Fraser <keir@xxxxxxx>
Delivery-date: Mon, 22 Aug 2011 20:54:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E528198020000780005291D@xxxxxxxxxxxxxxxxxxxx>
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: <749B9D3DBF0F054390025D9EAFF47F2212D123FC5C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E528198020000780005291D@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acxg1o39NltmdPMdRwe+6OdPuDvibwAaSKsQ
Thread-topic: [PATCH] Fix xen hang on intel westmere-EP
> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Monday, August 22, 2011 10:20 PM
> 
> I think we discussed (off-list) quite extensively that this should not be 
> keyed to
> the PCI device IDs. It ought to hang off the BIOS and/or board manufacturer. I
> actually have a patch that does just so, but am waiting for possibly more fine
> grained identification information from you (Intel).
> 
> Also, are you certain this problem exists only with this single ICH variant?
So far, we only observed it on ICH10 based chipset. Did you see another 
platform have the problems?

> > +    {}
> > +};
> > +
> > +static void check_quirk(unsigned int bus, unsigned int dev, unsigned
> > +int func) {
> > +    unsigned int vendor_id, device_id;
> > +    int i;
> > +
> > +    vendor_id = pci_conf_read16(bus, dev, func, PCI_VENDOR_ID);
> > +    device_id = pci_conf_read16(bus, dev, func, PCI_DEVICE_ID);
> > +
> > +    for (i = 0; early_quirk[i].f != NULL; i++)
> > +        if (early_quirk[i].vendor == vendor_id &&
> > +            early_quirk[i].device == device_id)
> > +                early_quirk[i].f(bus, dev, func); }
> > +
> > +void  __init early_quirks(void)
> > +{
> > +    unsigned int dev, func;
> > +
> > +    for (dev = 0; dev < 32; dev++)
> > +        for (func = 0; func < 8; func++)
> > +            check_quirk(0, dev, func);
> 
> 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.



best regards
yang

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