Discussion:
HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
(too old to reply)
Randy Dunlap
2017-05-13 19:28:03 UTC
Permalink
[adding HPET driver maintainer]
Thanks
A couple of comments below...
In BIOS, HPET's enabled.
How about if you just boot Linux without Xen? Does HPET show up then?
cat devices/system/clocksource/clocksource0/available
tsc hpet acpi_pm
Adding xen mailing list:

Is HPET support a known issue in Xen?

release : 4.11.0-4.gcb15206-default
xen_version : 4.9.0_04-493


Original message is here:
http://marc.info/?l=linux-kernel&m=149464267427111&w=2


Thanks.
[ 8.491738] hpet_acpi_add: no address or irqs in _CRS
Above line marks a big failure. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I suspected that's problematic.
In the non-Xen case
dmesg | grep -i hpet
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 00000005)
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[ 0.000000] hpet clockevent registered
[ 0.144010] DMAR-IR: HPET id 0 under DRHD base 0xfed90000
[ 1.398047] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[ 1.404226] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[ 1.412080] clocksource: Switched to clocksource hpet
[ 3.627234] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
--
~Randy
Andrew Cooper
2017-05-13 19:38:33 UTC
Permalink
Post by Randy Dunlap
[adding HPET driver maintainer]
Thanks
A couple of comments below...
In BIOS, HPET's enabled.
How about if you just boot Linux without Xen? Does HPET show up then?
cat devices/system/clocksource/clocksource0/available
tsc hpet acpi_pm
Is HPET support a known issue in Xen?
What is the issue here?

Xen owns (and may use) any HPETs in the system. They are purposefully
unavailable to even dom0.

~Andrew
PGNet Dev
2017-05-13 19:49:32 UTC
Permalink
Post by Andrew Cooper
What is the issue here?
Xen owns (and may use) any HPETs in the system. They are purposefully
unavailable to even dom0.
The issue is that, when booting to Xen, hpet is not advertised as an available clocksource, AND reports the hpet boot error pointed out by Randy.

Following

https://wiki.xen.org/wiki/Xen_power_management#HPET_as_broadcast_timer_source_.28clocksource.29_.3D

there's discussion there re: 'if HPET is available / not missing'.

It appears to be available only booting to non-Xen.

What specific indication does one look for that Xen's using available hpet?
Andrew Cooper
2017-05-13 19:59:37 UTC
Permalink
Post by PGNet Dev
Post by Andrew Cooper
What is the issue here?
Xen owns (and may use) any HPETs in the system. They are purposefully
unavailable to even dom0.
The issue is that, when booting to Xen, hpet is not advertised as an available clocksource, AND reports the hpet boot error pointed out by Randy.
Following
https://wiki.xen.org/wiki/Xen_power_management#HPET_as_broadcast_timer_source_.28clocksource.29_.3D
there's discussion there re: 'if HPET is available / not missing'.
It appears to be available only booting to non-Xen.
What specific indication does one look for that Xen's using available hpet?
Ok. Lack of a clocksource is to be expected.

The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.

Use `xl dmesg` to get to the hypervisor dmesg log. You should see
mention of the HPET in there if Xen has found it.

~Andrew
PGNet Dev
2017-05-13 20:05:22 UTC
Permalink
Post by Andrew Cooper
Ok. Lack of a clocksource is to be expected.
The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.
Use `xl dmesg` to get to the hypervisor dmesg log. You should see
mention of the HPET in there if Xen has found it.
back to the error at hand ...

xl dmesg | grep -i hpet
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS

again, only present when booting with Xen.

same kernel, no Xen, no such error.
Andrew Cooper
2017-05-13 20:16:17 UTC
Permalink
Post by PGNet Dev
Post by Andrew Cooper
Ok. Lack of a clocksource is to be expected.
The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.
Use `xl dmesg` to get to the hypervisor dmesg log. You should see
mention of the HPET in there if Xen has found it.
back to the error at hand ...
xl dmesg | grep -i hpet
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
again, only present when booting with Xen.
same kernel, no Xen, no such error.
We don't have code like that in upstream Xen. No function with that
name, or a string which looks like that error message.

http://marc.info/?l=linux-kernel&m=149464267427111&w=2 indicates that
you are using a SuSE hypervisor.

Jan/Juergen: Any ideas? This looks as if it is something local to your
patch queue.

~Andrew
PGNet Dev
2017-05-13 21:07:24 UTC
Permalink
Post by Andrew Cooper
We don't have code like that in upstream Xen. No function with that
name, or a string which looks like that error message.
noted
Post by Andrew Cooper
http://marc.info/?l=linux-kernel&m=149464267427111&w=2 indicates that
you are using a SuSE hypervisor.
yes, that's correct
Juergen Gross
2017-05-14 17:13:56 UTC
Permalink
Post by Andrew Cooper
Post by PGNet Dev
Post by Andrew Cooper
Ok. Lack of a clocksource is to be expected.
The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.
Use `xl dmesg` to get to the hypervisor dmesg log. You should see
mention of the HPET in there if Xen has found it.
back to the error at hand ...
xl dmesg | grep -i hpet
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
again, only present when booting with Xen.
same kernel, no Xen, no such error.
We don't have code like that in upstream Xen. No function with that
name, or a string which looks like that error message.
This is a Linux kernel message.


Juergen
PGNet Dev
2017-05-13 21:06:28 UTC
Permalink
Post by PGNet Dev
back to the error at hand ...
xl dmesg | grep -i hpet
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
again, only present when booting with Xen.
same kernel, no Xen, no such error.
Are you sure this is `xl dmesg`
yep.

xl dmesg | grep -i hpet | grep -vi command
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
and not `dmesg` output?
AND

dmesg | grep -i hpet | grep -vi command
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM
SMCI--MB 01072009 AMI. 00000005)
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
PGNet Dev
2017-05-13 21:58:54 UTC
Permalink
Post by PGNet Dev
xl dmesg | grep -i hpet | grep -vi command
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
[ 1.365876] hpet_acpi_add: no address or irqs in _CRS
Ah, guess this is caused by console_to_ring boot option.
Better check you are not missing info from the Xen ring buffer.
Interesting.

With, currently,

GRUB_CMDLINE_LINUX_XEN_REPLACE="... systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8"

and

GRUB_CMDLINE_XEN=" ... console_timestamps console_to_ring conring_size=64 sched=credit2 sched_debug log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all guest_loglvl=all noreboot=false sync_console=true"

I've only

xl dmesg | head
299] sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
[ 9.449299] sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
[ 9.449300] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[ 9.449300] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[ 9.449328] sd 1:0:0:0: [sdb] Write Protect is off
[ 9.449328] sd 1:0:0:0: [sdb] Write Protect is off
[ 9.449329] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 9.449329] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 9.449347] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 9.449347] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Whereas in serial console,

Booting `OpenSUSE, with Xen hypervisor'Booting `OpenSUSE, with Xen hypervisor'



Loading Xen 4.9.0_04-493 with Linux 4.11.0-4.gcb15206-default ...Loading Xen 4.9.0_04-493 wit
h Linux 4.11.0-4.gcb15206-default ...

/EndEntire
/EndEntire
file path: file path: /ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/
PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor
(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1:
/HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 ]]/HD(2,1000,96000,c5cc9661271
ee648
,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE)
/File(\EFI\OPENSUSE)/File(xen-4.9.0_04-493.efi)/File(xen-4.9.0_04-493.efi)/EndEntire
/EndEntire
Xen 4.9.0_04-493 (c/s ) EFI loader
Using configuration file 'xen-4.9.0_04-493.cfg'
vmlinuz-4.11.0-4.gcb15206-default: 0x000000008b986000-0x000000008c06bf60
initrd-4.11.0-4.gcb15206-default: 0x000000008aab2000-0x000000008b985978
0x0000:0x00:0x19.0x0: ROM: 0x10000 bytes at 0x928a7018
0x0000:0x04:0x00.0x0: ROM: 0x8000 bytes at 0x9289e018
0x0000:0x10:0x00.0x0: ROM: 0x10800 bytes at 0x9287d018
__ __ _ _ ___ ___ ___ _ _ _ _ ___ _____
\ \/ /___ _ __ | || | / _ \ / _ \ / _ \| || | | || | / _ \___ /
\ // _ \ '_ \ | || || (_) | | | | | | | | || |_ __| || || (_) ||_ \
/ \ __/ | | | |__ _\__, | |_| | | |_| |__ _|__|__ _\__, |__) |
/_/\_\___|_| |_| |_|(_)/_(_)___/___\___/ |_| |_| /_/____/
|_____|
(XEN) Xen version 4.9.0_04-493 (***@suse.de) (gcc (SUSE Linux) 4.8.5) debug=y Wed May 10
21:26:38 UTC 2017
(XEN) Latest ChangeSet:
(XEN) Console output is synchronous.
(XEN) Bootloader: EFI
(XEN) Command line: dom0_mem=4096M,max:4096M dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=11520
0,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 s
ched_debug reboot=acpi log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all guest_
loglvl=all noreboot=false sync_console=true
(XEN) Xen image load base address: 0x8c200000
(XEN) Video information:
(XEN) VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 6 EDD information structures
(XEN) EFI RAM map:
(XEN) 0000000000000000 - 0000000000008000 (reserved)
(XEN) 0000000000008000 - 0000000000048000 (usable)
...

Searching the *console* output for 'hpet',

grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verb
ose clocksource=hpet net.ifnames=1 biosdevname=1 pcie_aspm=off m
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=for
ce,verbose clocksource=hpet net.ifnames=1 biosdevname=1 pcie_asp
=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verb
ose clocksource=hpet net.ifnames=1 biosdevname=1 pcie_aspm=off m
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=for
ce,verbose clocksource=hpet net.ifnames=1 biosdevname=1 pcie_asp
[ 8.489692] hpet_acpi_add: no address or irqs in _CRS
[ 8.489692] hpet_acpi_add: no address or irqs in _CRS
(XEN) [2017-05-13 21:40:15] HVM1 save: HPET

and, still

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc


Does this perhaps imply that Xen correctly uses HPET

(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) Platform timer is 14.318MHz HPET

, noting:

"If h/w supports per-channel MSI delivery mode (intr via FSB)," it's the best broadcast mechanism known so far"

but that Dom0 does not

current_clocksource
tsc

?
PGNet Dev
2017-05-13 23:17:57 UTC
Permalink
Try booting without 'hpet=force,verbose clocksource=hpet' and it should
Nope. Well, not quite ...

With both

'hpet=force,verbose clocksource=hpet'

removed, I end up with

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

But with

clocksource=xen

*explicitly* added

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
xen

and in *console*, NOT dmesg, output,

grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
(XEN) [2017-05-13 23:04:27] HVM1 save: HPET



and

dmesg | grep -i clocksource | grep -v line:
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.004000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.375709] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 4.656634] clocksource: Switched to clocksource xen
[ 8.912897] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns

jiffies, now? hm. no idea where that came from. and why the 'tsc' ?

So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
Andrew Cooper
2017-05-14 15:39:37 UTC
Permalink
Post by PGNet Dev
Try booting without 'hpet=force,verbose clocksource=hpet' and it should
Nope. Well, not quite ...
With both
'hpet=force,verbose clocksource=hpet'
removed, I end up with
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
But with
clocksource=xen
*explicitly* added
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
xen
and in *console*, NOT dmesg, output,
grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
(XEN) [2017-05-13 23:04:27] HVM1 save: HPET
and
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.004000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.375709] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 4.656634] clocksource: Switched to clocksource xen
[ 8.912897] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns
jiffies, now? hm. no idea where that came from. and why the 'tsc' ?
So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
What are you trying to achieve? It is still not clear despite all on
this thread.

The Linux HEPT error messages are non-ideal, but there is no way dom0
will ever be able to use clocksource=hpet when running under Xen.

~Andrew
Randy Dunlap
2017-05-14 17:41:17 UTC
Permalink
Post by Andrew Cooper
Post by PGNet Dev
Try booting without 'hpet=force,verbose clocksource=hpet' and it should
Nope. Well, not quite ...
With both
'hpet=force,verbose clocksource=hpet'
removed, I end up with
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
But with
clocksource=xen
*explicitly* added
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
xen
and in *console*, NOT dmesg, output,
grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
(XEN) [2017-05-13 23:04:27] HVM1 save: HPET
and
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.004000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.375709] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 4.656634] clocksource: Switched to clocksource xen
[ 8.912897] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns
jiffies, now? hm. no idea where that came from. and why the 'tsc' ?
So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
What are you trying to achieve? It is still not clear despite all on
this thread.
I agree. Are you (pgnet.dev) just curious about why the Xen kernel does
not expose HPET as a clocksource or is not having it causing some problem
for you or some specific software application?
Post by Andrew Cooper
The Linux HEPT error messages are non-ideal, but there is no way dom0
will ever be able to use clocksource=hpet when running under Xen.
--
~Randy
Austin S. Hemmelgarn
2017-05-15 18:06:32 UTC
Permalink
Post by PGNet Dev
Try booting without 'hpet=force,verbose clocksource=hpet' and it should
Nope. Well, not quite ...
With both
'hpet=force,verbose clocksource=hpet'
removed, I end up with
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
But with
clocksource=xen
*explicitly* added
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
xen
and in *console*, NOT dmesg, output,
grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 000000
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
[ 8.515245] hpet_acpi_add: no address or irqs in _CRS
(XEN) [2017-05-13 23:04:27] HVM1 save: HPET
and
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.004000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.375709] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 4.656634] clocksource: Switched to clocksource xen
[ 8.912897] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns
jiffies, now? hm. no idea where that came from. and why the 'tsc' ?
So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
That depends on what you mean by everything correctly using the HPET.
Using clocksource=xen (or autoselecting it) will cause the kernel to get
timing info from Xen. If you're running as a guest, this is absolutely
what you want (unless you're using HVM), and with possible limited and
extremely specific exceptions, this is almost certainly what you want in
Domain-0 as well. Given that Xen is using the HPEt for timing itself,
using clocksource=xen will result in Linux _indirectly_ using the HPET
through Xen without involving the HPET driver (in essence, Xen is your
HPET driver in this situation), which will get you essentially the same
precision that you would get by using the HPET directly.

So, if you just want the precision offered by the HPET, then yes, you
are getting the same thing through the Xen clocksource.
PGNet Dev
2017-05-17 00:12:30 UTC
Permalink
_______________________________________________
Xen-devel mailing list
Xen-***@lists.xen.org
https://lists.xen
PGNet Dev
2017-05-17 00:15:24 UTC
Permalink
(apologies re: the empty 'double tap' :-/ )
Post by Andrew Cooper
Post by PGNet Dev
So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
What are you trying to achieve? It is still not clear despite all on
this thread.
The Linux HEPT error messages are non-ideal, but there is no way dom0
will ever be able to use clocksource=hpet when running under Xen.
What I'm trying to achieve is to

(a) understand, in general
(b) correctly implement HPET usage in Xen
&
(c) understand &, as needed, remediate the warnings/error message that seem(ed) to be associated

I.e. -- what exactly needs be done, and what should be the observable results, when "using" HPET with Xen. It's simply not obvious from the docs.

The docs here,

https://wiki.xen.org/wiki/Xen_power_management

are ... somewhat challenging:

"By far Xen3.4 supports PIT/HPET as the broadcast source.
...
HPET as broadcast timer source (clocksource) =
...
HPET can delivery timely wakeup event to CPUs sleep in deep C-states with negligible overhead, as stated earlier. But HPET mode being used does make some differences to worthy of our noting:

If h/w supports per-channel MSI delivery mode (intr via FSB), it's the best broadcast mechanism known so far.
...
"

??
Post by Andrew Cooper
That depends on what you mean by everything correctly using the HPET.
Using clocksource=xen (or autoselecting it) will cause the kernel to get
timing info from Xen. If you're running as a guest, this is absolutely
what you want (unless you're using HVM), and with possible limited and
extremely specific exceptions, this is almost certainly what you want in
Domain-0 as well. Given that Xen is using the HPEt for timing itself,
using clocksource=xen will result in Linux _indirectly_ using the HPET
through Xen without involving the HPET driver (in essence, Xen is your
HPET driver in this situation), which will get you essentially the same
precision that you would get by using the HPET directly.
So, if you just want the precision offered by the HPET, then yes, you
are getting the same thing through the Xen clocksource.
Is legible, understandable & helpfully informative. (Thanks, Austin! Valentin's comments helped as well.)

'tho further detail on common &/or "limited and extremely specific exceptions" use-cases of PVH, HVM, PVHVM & HVM2 will be useful, I'd heartily recommend that some version of Austin's comment be added to the docs/wiki as a nice doc-step forward.
Continue reading on narkive:
Loading...