| Message ID | 26a90632-bb76-a24b-aef1-4c068b610c6a@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: avoid HPET use also on certain Coffee Lake H | expand |
On 25.05.2020 17:18, Jan Beulich wrote: > Linux commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 says > > "Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET > timer once the SoCs entered PC10." > > Again follow this for Xen as well, noting though that even the > pre-existing PCI ID refers to a H-processor line variant (the 6-core > one). It is also suspicious that the datasheet names 0x3e10 for the > 4-core variant, while the Linux commit specifies 0x3e20, which I haven't > been able to locate in any datasheet yet. To be on the safe side, add > both until clarification can be provided by Intel. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> I'd like to note that I've been sitting on this for several months, hoping to be able to submit with less uncertainty. I shall further note that I'm sitting on a similar Ice Lake patch, triggered by seeing Linux'es e0748539e3d594dd26f0d27a270f14720b22a406. The situation seems even worse there - I can't make datasheet and Linux commit match even remotely, PCI-ID-wise. I didn't think it makes sense to submit a patch in such a case. Jan
On 25/05/2020 16:23, Jan Beulich wrote: > On 25.05.2020 17:18, Jan Beulich wrote: >> Linux commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 says >> >> "Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET >> timer once the SoCs entered PC10." >> >> Again follow this for Xen as well, noting though that even the >> pre-existing PCI ID refers to a H-processor line variant (the 6-core >> one). It is also suspicious that the datasheet names 0x3e10 for the >> 4-core variant, while the Linux commit specifies 0x3e20, which I haven't >> been able to locate in any datasheet yet. 3e20 is the host bridge ID for CFL-R (Gen 9) Core i9 (8c/16t) as found in the Dell XPS 15 7590 amongst other things. As such, it is a generation later than CFL. >> To be on the safe side, add >> both until clarification can be provided by Intel. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> Given the nature of issue (a power efficiently "feature" rather than a bug), it will likely affect everything in a couple of generations worth of CPUs. The issue may not actually affect Xen yet, because I don't expect we've got S0ix working yet. It is only a problem on entry to S0i2/3 where the HPET is halted. > I'd like to note that I've been sitting on this for several months, > hoping to be able to submit with less uncertainty. I shall further > note that I'm sitting on a similar Ice Lake patch, triggered by > seeing Linux'es e0748539e3d594dd26f0d27a270f14720b22a406. The > situation seems even worse there - I can't make datasheet and > Linux commit match even remotely, PCI-ID-wise. I didn't think it > makes sense to submit a patch in such a case. 0x8a12 is an ID in the middle of a load of Ice Lake IDs, according to the PCI-ID database, but there isn't entry specifically for it. I can't find a datasheet either for it. ~Andrew
On 25.05.2020 19:30, Andrew Cooper wrote: > On 25/05/2020 16:23, Jan Beulich wrote: >> On 25.05.2020 17:18, Jan Beulich wrote: >>> Linux commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 says >>> >>> "Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET >>> timer once the SoCs entered PC10." >>> >>> Again follow this for Xen as well, noting though that even the >>> pre-existing PCI ID refers to a H-processor line variant (the 6-core >>> one). It is also suspicious that the datasheet names 0x3e10 for the >>> 4-core variant, while the Linux commit specifies 0x3e20, which I haven't >>> been able to locate in any datasheet yet. > > 3e20 is the host bridge ID for CFL-R (Gen 9) Core i9 (8c/16t) as found > in the Dell XPS 15 7590 amongst other things. > > As such, it is a generation later than CFL. Ah, and I should have checked again before submitting - the pretty new rev 003 datasheet actually includes all three IDs now. I've adjusted description and code comments accordingly. >>> To be on the safe side, add >>> both until clarification can be provided by Intel. >>> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Given the nature of issue (a power efficiently "feature" rather than a > bug), it will likely affect everything in a couple of generations worth > of CPUs. > > The issue may not actually affect Xen yet, because I don't expect we've > got S0ix working yet. It is only a problem on entry to S0i2/3 where the > HPET is halted. While looking into this a while ago I cam across this as well, but I couldn't deduce whether entering PC10 is indeed possible _only_ this way. Jan
--- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -397,10 +397,16 @@ static int64_t __init init_hpet(struct p * entered PC10. */ if ( pci_conf_read16(PCI_SBDF(0, 0, 0, 0), - PCI_VENDOR_ID) == PCI_VENDOR_ID_INTEL && - pci_conf_read16(PCI_SBDF(0, 0, 0, 0), - PCI_DEVICE_ID) == 0x3ec4 ) - hpet_address = 0; + PCI_VENDOR_ID) == PCI_VENDOR_ID_INTEL ) + switch ( pci_conf_read16(PCI_SBDF(0, 0, 0, 0), + PCI_DEVICE_ID) ) + { + case 0x3e10: /* as per datasheet (4 core variant) */ + case 0x3e20: /* as per respective Linux commit */ + case 0x3ec4: + hpet_address = 0; + break; + } if ( !hpet_address ) printk("Disabling HPET for being unreliable\n");
Linux commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 says "Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET timer once the SoCs entered PC10." Again follow this for Xen as well, noting though that even the pre-existing PCI ID refers to a H-processor line variant (the 6-core one). It is also suspicious that the datasheet names 0x3e10 for the 4-core variant, while the Linux commit specifies 0x3e20, which I haven't been able to locate in any datasheet yet. To be on the safe side, add both until clarification can be provided by Intel. Signed-off-by: Jan Beulich <jbeulich@suse.com>