[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.