* HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? @ 2017-05-13 2:30 PGNet Dev 2017-05-13 17:41 ` Randy Dunlap 0 siblings, 1 reply; 24+ messages in thread From: PGNet Dev @ 2017-05-13 2:30 UTC (permalink / raw) To: linux-kernel I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard. HPET's enabled in BIOS, and apparently firmware table data is available. But, hpet is not an available_clocksource. Where's this need to be addressed/fixed? In my config, in kernel code, &/or in BIOS? info: @ the mobo, dmidecode # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 2.7 present. 81 structures occupying 3317 bytes. Table at 0x000EC200. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 3.0 Release Date: 05/26/2015 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 16384 kB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 4.6 In BIOS, HPET's enabled. On boot to Xen on linux64 xl info release : 4.11.0-4.gcb15206-default version : #1 SMP PREEMPT Thu May 11 07:36:09 UTC 2017 (cb15206) machine : x86_64 nr_cpus : 4 max_cpu_id : 3 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz : 3092 hw_caps : bfebfbff:77faf3ff:2c100800:00000021:00000001:000027ab:00000000:00000100 virt_caps : hvm hvm_directio total_memory : 32493 free_memory : 25899 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 9 xen_extra : .0_04-493 xen_version : 4.9.0_04-493 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit2 xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : xen_commandline : dom0_mem=4096M,max:4096M dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 sched_debug reboot=acpi log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all guest_loglvl=all noreboot=false sync_console=true cc_compiler : gcc (SUSE Linux) 4.8.5 cc_compile_by : abuild cc_compile_domain : suse.de cc_compile_date : Wed May 10 21:26:38 UTC 2017 build_id : dde541fac1512c7b1ce17e7496aab57a xend_config_format : 4 grep -i hpet /boot/config-4.11.0-4.gcb15206-default CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_HPET_MMAP_DEFAULT=y , dmesg reports dmesg | grep -i hpet [ 0.000000] Command line: root=/dev/mapper/VG0_ROOT rd.shell rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose net.ifnames=1 biosdevname=1 pcie_aspm=off mce=off nomodeset showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8 [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 00000005) [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 0.000000] Kernel command line: root=/dev/mapper/VG0_ROOT rd.shell rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose net.ifnames=1 biosdevname=1 pcie_aspm=off mce=off nomodeset showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8 [ 8.491738] hpet_acpi_add: no address or irqs in _CRS After boot, however, no hpet clocksource is available cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc xen Disassembling the firmware acpi tables cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out iasl -d /var/tmp/hpet.out Intel ACPI Component Architecture ASL Optimizing Compiler version 20140214-64 Copyright (c) 2000 - 2014 Intel Corporation Loading Acpi table from file /var/tmp/hpet.out - Length 00000056 (000038) Acpi Data Table [HPET] decoded Formatted output: /var/tmp/hpet.dsl - 1835 bytes cat /var/tmp/hpet.dsl /* * Intel ACPI Component Architecture * AML Disassembler version 20140214-64 * Copyright (c) 2000 - 2014 Intel Corporation * * Disassembly of /var/tmp/hpet.out, Fri May 12 18:46:28 2017 * * ACPI Data Table [HPET] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 0000 4] Signature : "HPET" [High Precision Event Timer table] [004h 0004 4] Table Length : 00000038 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : 89 [00Ah 0010 6] Oem ID : "SUPERM" [010h 0016 8] Oem Table ID : "SMCI--MB" [018h 0024 4] Oem Revision : 01072009 [01Ch 0028 4] Asl Compiler ID : "AMI." [020h 0032 4] Asl Compiler Revision : 00000005 [024h 0036 4] Hardware Block ID : 8086A701 [028h 0040 12] Timer Block Register : [Generic Address Structure] [028h 0040 1] Space ID : 00 [SystemMemory] [029h 0041 1] Bit Width : 40 [02Ah 0042 1] Bit Offset : 00 [02Bh 0043 1] Encoded Access Width : 00 [Undefined/Legacy] [02Ch 0044 8] Address : 00000000FED00000 [034h 0052 1] Sequence Number : 00 [035h 0053 2] Minimum Clock Ticks : 37EE [037h 0055 1] Flags (decoded below) : 00 4K Page Protect : 0 64K Page Protect : 0 Raw Table Data: Length 56 (0x38) 0000: 48 50 45 54 38 00 00 00 01 89 53 55 50 45 52 4D HPET8.....SUPERM 0010: 53 4D 43 49 2D 2D 4D 42 09 20 07 01 41 4D 49 2E SMCI--MB. ..AMI. 0020: 05 00 00 00 01 A7 86 80 00 40 00 00 00 00 D0 FE .........@...... 0030: 00 00 00 00 00 EE 37 00 ......7. and for ref cat /proc/sys/dev/hpet /proc/sys/dev/hpet cat /proc/sys/dev/hpet/max-user-freq /proc/driver/rtc 64 rtc_time : 01:44:28 rtc_date : 2017-05-13 alrm_time : 21:02:26 alrm_date : 2017-05-13 alarm_IRQ : no alrm_pending : no update IRQ enabled : no periodic IRQ enabled : no periodic IRQ frequency : 1024 max user IRQ frequency : 64 24hr : yes periodic_IRQ : no update_IRQ : no HPET_emulated : no BCD : yes DST_enable : no periodic_freq : 1024 batt_status : okay ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 2:30 HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? PGNet Dev @ 2017-05-13 17:41 ` Randy Dunlap 2017-05-13 18:26 ` PGNet Dev 2017-05-13 19:45 ` Clemens Ladisch 0 siblings, 2 replies; 24+ messages in thread From: Randy Dunlap @ 2017-05-13 17:41 UTC (permalink / raw) To: pgnet.dev, linux-kernel, Clemens Ladisch [adding HPET driver maintainer] A couple of comments below... On 05/12/17 19:30, PGNet Dev wrote: > I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard. > > HPET's enabled in BIOS, and apparently firmware table data is available. > > But, hpet is not an available_clocksource. > > Where's this need to be addressed/fixed? In my config, in kernel code, &/or in BIOS? > > info: > > @ the mobo, > > dmidecode > # dmidecode 3.0 > Getting SMBIOS data from sysfs. > SMBIOS 2.7 present. > 81 structures occupying 3317 bytes. > Table at 0x000EC200. > > Handle 0x0000, DMI type 0, 24 bytes > BIOS Information > Vendor: American Megatrends Inc. > Version: 3.0 > Release Date: 05/26/2015 > Address: 0xF0000 > Runtime Size: 64 kB > ROM Size: 16384 kB > Characteristics: > PCI is supported > BIOS is upgradeable > BIOS shadowing is allowed > Boot from CD is supported > Selectable boot is supported > BIOS ROM is socketed > EDD is supported > 5.25"/1.2 MB floppy services are supported (int 13h) > 3.5"/720 kB floppy services are supported (int 13h) > 3.5"/2.88 MB floppy services are supported (int 13h) > Print screen service is supported (int 5h) > 8042 keyboard services are supported (int 9h) > Serial services are supported (int 14h) > Printer services are supported (int 17h) > ACPI is supported > USB legacy is supported > BIOS boot specification is supported > Targeted content distribution is supported > UEFI is supported > BIOS Revision: 4.6 > > In BIOS, HPET's enabled. How about if you just boot Linux without Xen? Does HPET show up then? > On boot to Xen on linux64 > > xl info > release : 4.11.0-4.gcb15206-default > version : #1 SMP PREEMPT Thu May 11 07:36:09 UTC 2017 (cb15206) > machine : x86_64 > nr_cpus : 4 > max_cpu_id : 3 > nr_nodes : 1 > cores_per_socket : 4 > threads_per_core : 1 > cpu_mhz : 3092 > hw_caps : bfebfbff:77faf3ff:2c100800:00000021:00000001:000027ab:00000000:00000100 > virt_caps : hvm hvm_directio > total_memory : 32493 > free_memory : 25899 > sharing_freed_memory : 0 > sharing_used_memory : 0 > outstanding_claims : 0 > free_cpus : 0 > xen_major : 4 > xen_minor : 9 > xen_extra : .0_04-493 > xen_version : 4.9.0_04-493 > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 > xen_scheduler : credit2 > xen_pagesize : 4096 > platform_params : virt_start=0xffff800000000000 > xen_changeset : > xen_commandline : dom0_mem=4096M,max:4096M dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 sched_debug reboot=acpi log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all guest_loglvl=all noreboot=false sync_console=true > cc_compiler : gcc (SUSE Linux) 4.8.5 > cc_compile_by : abuild > cc_compile_domain : suse.de > cc_compile_date : Wed May 10 21:26:38 UTC 2017 > build_id : dde541fac1512c7b1ce17e7496aab57a > xend_config_format : 4 > > grep -i hpet /boot/config-4.11.0-4.gcb15206-default > CONFIG_HPET_TIMER=y > CONFIG_HPET_EMULATE_RTC=y > CONFIG_HPET=y > CONFIG_HPET_MMAP=y > CONFIG_HPET_MMAP_DEFAULT=y > > > , dmesg reports > > dmesg | grep -i hpet > [ 0.000000] Command line: root=/dev/mapper/VG0_ROOT rd.shell rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose net.ifnames=1 biosdevname=1 pcie_aspm=off mce=off nomodeset showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8 > [ 0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 00000005) > [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 > [ 0.000000] Kernel command line: root=/dev/mapper/VG0_ROOT rd.shell rd.auto=1 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand hpet=force,verbose net.ifnames=1 biosdevname=1 pcie_aspm=off mce=off nomodeset showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=debug systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8 > [ 8.491738] hpet_acpi_add: no address or irqs in _CRS Above line marks a big failure. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > After boot, however, no hpet clocksource is available > > cat /sys/devices/system/clocksource/clocksource0/available_clocksource > tsc xen > > Disassembling the firmware acpi tables > > cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out > iasl -d /var/tmp/hpet.out > Intel ACPI Component Architecture > ASL Optimizing Compiler version 20140214-64 > Copyright (c) 2000 - 2014 Intel Corporation > > Loading Acpi table from file /var/tmp/hpet.out - Length 00000056 (000038) > Acpi Data Table [HPET] decoded > Formatted output: /var/tmp/hpet.dsl - 1835 bytes > > cat /var/tmp/hpet.dsl > /* > * Intel ACPI Component Architecture > * AML Disassembler version 20140214-64 > * Copyright (c) 2000 - 2014 Intel Corporation > * > * Disassembly of /var/tmp/hpet.out, Fri May 12 18:46:28 2017 > * > * ACPI Data Table [HPET] > * > * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue > */ > > [000h 0000 4] Signature : "HPET" [High Precision Event Timer table] > [004h 0004 4] Table Length : 00000038 > [008h 0008 1] Revision : 01 > [009h 0009 1] Checksum : 89 > [00Ah 0010 6] Oem ID : "SUPERM" > [010h 0016 8] Oem Table ID : "SMCI--MB" > [018h 0024 4] Oem Revision : 01072009 > [01Ch 0028 4] Asl Compiler ID : "AMI." > [020h 0032 4] Asl Compiler Revision : 00000005 > > [024h 0036 4] Hardware Block ID : 8086A701 > > [028h 0040 12] Timer Block Register : [Generic Address Structure] > [028h 0040 1] Space ID : 00 [SystemMemory] > [029h 0041 1] Bit Width : 40 > [02Ah 0042 1] Bit Offset : 00 > [02Bh 0043 1] Encoded Access Width : 00 [Undefined/Legacy] > [02Ch 0044 8] Address : 00000000FED00000 > > [034h 0052 1] Sequence Number : 00 > [035h 0053 2] Minimum Clock Ticks : 37EE > [037h 0055 1] Flags (decoded below) : 00 > 4K Page Protect : 0 > 64K Page Protect : 0 > > Raw Table Data: Length 56 (0x38) > > 0000: 48 50 45 54 38 00 00 00 01 89 53 55 50 45 52 4D HPET8.....SUPERM > 0010: 53 4D 43 49 2D 2D 4D 42 09 20 07 01 41 4D 49 2E SMCI--MB. ..AMI. > 0020: 05 00 00 00 01 A7 86 80 00 40 00 00 00 00 D0 FE .........@...... > 0030: 00 00 00 00 00 EE 37 00 ......7. > > and for ref > > cat /proc/sys/dev/hpet /proc/sys/dev/hpet > cat /proc/sys/dev/hpet/max-user-freq /proc/driver/rtc > 64 > rtc_time : 01:44:28 > rtc_date : 2017-05-13 > alrm_time : 21:02:26 > alrm_date : 2017-05-13 > alarm_IRQ : no > alrm_pending : no > update IRQ enabled : no > periodic IRQ enabled : no > periodic IRQ frequency : 1024 > max user IRQ frequency : 64 > 24hr : yes > periodic_IRQ : no > update_IRQ : no > HPET_emulated : no > BCD : yes > DST_enable : no > periodic_freq : 1024 > batt_status : okay > -- ~Randy ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 17:41 ` Randy Dunlap @ 2017-05-13 18:26 ` PGNet Dev 2017-05-13 19:28 ` Randy Dunlap 2017-05-13 19:45 ` Clemens Ladisch 1 sibling, 1 reply; 24+ messages in thread From: PGNet Dev @ 2017-05-13 18:26 UTC (permalink / raw) To: Randy Dunlap, linux-kernel, Clemens Ladisch On 5/13/17 10:41 AM, Randy Dunlap wrote: > [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? yes, it appears so: cat devices/system/clocksource/clocksource0/available tsc hpet acpi_pm >> [ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 18:26 ` PGNet Dev @ 2017-05-13 19:28 ` Randy Dunlap 2017-05-13 19:38 ` [Xen-devel] " Andrew Cooper 0 siblings, 1 reply; 24+ messages in thread From: Randy Dunlap @ 2017-05-13 19:28 UTC (permalink / raw) To: pgnet.dev, linux-kernel, Clemens Ladisch, xen-devel On 05/13/17 11:26, PGNet Dev wrote: > On 5/13/17 10:41 AM, Randy Dunlap wrote: >> [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? > > yes, it appears so: > > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 19:28 ` Randy Dunlap @ 2017-05-13 19:38 ` Andrew Cooper 2017-05-13 19:49 ` PGNet Dev 0 siblings, 1 reply; 24+ messages in thread From: Andrew Cooper @ 2017-05-13 19:38 UTC (permalink / raw) To: Randy Dunlap, pgnet.dev, linux-kernel, Clemens Ladisch, xen-devel On 13/05/2017 20:28, Randy Dunlap wrote: > On 05/13/17 11:26, PGNet Dev wrote: >> On 5/13/17 10:41 AM, Randy Dunlap wrote: >>> [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? >> yes, it appears so: >> >> cat devices/system/clocksource/clocksource0/available >> tsc hpet acpi_pm > Adding xen mailing list: > > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 19:38 ` [Xen-devel] " Andrew Cooper @ 2017-05-13 19:49 ` PGNet Dev 2017-05-13 19:59 ` Andrew Cooper 0 siblings, 1 reply; 24+ messages in thread From: PGNet Dev @ 2017-05-13 19:49 UTC (permalink / raw) To: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On 5/13/17 12:38 PM, Andrew Cooper wrote: > 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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 19:49 ` PGNet Dev @ 2017-05-13 19:59 ` Andrew Cooper 2017-05-13 20:05 ` PGNet Dev 0 siblings, 1 reply; 24+ messages in thread From: Andrew Cooper @ 2017-05-13 19:59 UTC (permalink / raw) To: pgnet.dev, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On 13/05/2017 20:49, PGNet Dev wrote: > On 5/13/17 12:38 PM, Andrew Cooper wrote: >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 19:59 ` Andrew Cooper @ 2017-05-13 20:05 ` PGNet Dev 2017-05-13 20:16 ` Andrew Cooper 2017-05-13 20:28 ` Valentin Vidic 0 siblings, 2 replies; 24+ messages in thread From: PGNet Dev @ 2017-05-13 20:05 UTC (permalink / raw) To: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On 5/13/17 12:59 PM, Andrew Cooper wrote: > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 20:05 ` PGNet Dev @ 2017-05-13 20:16 ` Andrew Cooper 2017-05-13 21:07 ` PGNet Dev 2017-05-14 17:13 ` Juergen Gross 2017-05-13 20:28 ` Valentin Vidic 1 sibling, 2 replies; 24+ messages in thread From: Andrew Cooper @ 2017-05-13 20:16 UTC (permalink / raw) To: pgnet.dev, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel, Juergen Gross Cc: Jan Beulich On 13/05/2017 21:05, PGNet Dev wrote: > On 5/13/17 12:59 PM, Andrew Cooper wrote: >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 20:16 ` Andrew Cooper @ 2017-05-13 21:07 ` PGNet Dev 2017-05-14 17:13 ` Juergen Gross 1 sibling, 0 replies; 24+ messages in thread From: PGNet Dev @ 2017-05-13 21:07 UTC (permalink / raw) To: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel, Juergen Gross Cc: Jan Beulich On 5/13/17 1:16 PM, Andrew Cooper wrote: > 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 > http://marc.info/?l=linux-kernel&m=149464267427111&w=2 indicates that > you are using a SuSE hypervisor. yes, that's correct ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 20:16 ` Andrew Cooper 2017-05-13 21:07 ` PGNet Dev @ 2017-05-14 17:13 ` Juergen Gross 1 sibling, 0 replies; 24+ messages in thread From: Juergen Gross @ 2017-05-14 17:13 UTC (permalink / raw) To: Andrew Cooper, pgnet.dev, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel Cc: Jan Beulich On 13/05/17 22:16, Andrew Cooper wrote: > On 13/05/2017 21:05, PGNet Dev wrote: >> On 5/13/17 12:59 PM, Andrew Cooper wrote: >>> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 20:05 ` PGNet Dev 2017-05-13 20:16 ` Andrew Cooper @ 2017-05-13 20:28 ` Valentin Vidic 2017-05-13 21:06 ` PGNet Dev 1 sibling, 1 reply; 24+ messages in thread From: Valentin Vidic @ 2017-05-13 20:28 UTC (permalink / raw) To: PGNet Dev Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote: > 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` and not `dmesg` output? On Debian jessie it looks like the hypervisor is using HPET by default as expected: # xl dmesg | grep -i hpet (XEN) ACPI: HPET 7986E860, 0038 (r1 SUPERM SMCI--MB 1 INTL 20091013) (XEN) Platform timer is 14.318MHz HPET # dmesg | grep -i hpet [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 64.157167] hpet_acpi_add: no address or irqs in _CRS -- Valentin ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 20:28 ` Valentin Vidic @ 2017-05-13 21:06 ` PGNet Dev 2017-05-13 21:32 ` Valentin Vidic 0 siblings, 1 reply; 24+ messages in thread From: PGNet Dev @ 2017-05-13 21:06 UTC (permalink / raw) To: Valentin Vidic Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On 5/13/17 1:28 PM, Valentin Vidic wrote: > On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote: >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 21:06 ` PGNet Dev @ 2017-05-13 21:32 ` Valentin Vidic 2017-05-13 21:58 ` PGNet Dev 0 siblings, 1 reply; 24+ messages in thread From: Valentin Vidic @ 2017-05-13 21:32 UTC (permalink / raw) To: PGNet Dev Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote: > 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. It should start with the Xen version like this: # xl dmesg | head (XEN) Xen version 4.4.1 (Debian 4.4.1-9+deb8u9) (ijackson@chiark.greenend.org.uk) (gcc (Debian 4.9.2-10) 4.9.2) debug=n Mon May 8 16:01:37 UTC 2017 (XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1 (XEN) Command line: placeholder dom0_mem=2048M com2=115200,8n1 console=com2,vga (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 1 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures -- Valentin ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 21:32 ` Valentin Vidic @ 2017-05-13 21:58 ` PGNet Dev 2017-05-13 22:15 ` Valentin Vidic 0 siblings, 1 reply; 24+ messages in thread From: PGNet Dev @ 2017-05-13 21:58 UTC (permalink / raw) To: Valentin Vidic Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On 5/13/17 2:32 PM, Valentin Vidic wrote: > On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote: >> 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. > It should start with the Xen version like this: > 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 (abuild@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 ? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 21:58 ` PGNet Dev @ 2017-05-13 22:15 ` Valentin Vidic 2017-05-13 23:17 ` PGNet Dev 0 siblings, 1 reply; 24+ messages in thread From: Valentin Vidic @ 2017-05-13 22:15 UTC (permalink / raw) To: PGNet Dev Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On Sat, May 13, 2017 at 02:58:54PM -0700, PGNet Dev wrote: > 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 I think so, yes. > but that Dom0 does not > > current_clocksource > tsc Try booting without 'hpet=force,verbose clocksource=hpet' and it should select xen by default: # dmesg | grep -i clocksource [ 58.944215] Switched to clocksource xen -- Valentin ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 22:15 ` Valentin Vidic @ 2017-05-13 23:17 ` PGNet Dev 2017-05-14 15:39 ` Andrew Cooper 2017-05-15 18:06 ` Austin S. Hemmelgarn 0 siblings, 2 replies; 24+ messages in thread From: PGNet Dev @ 2017-05-13 23:17 UTC (permalink / raw) To: Valentin Vidic Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On 5/13/17 3:15 PM, Valentin Vidic wrote: > Try booting without 'hpet=force,verbose clocksource=hpet' and it should > select xen by default: 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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 23:17 ` PGNet Dev @ 2017-05-14 15:39 ` Andrew Cooper 2017-05-14 17:41 ` Randy Dunlap 2017-05-15 18:06 ` Austin S. Hemmelgarn 1 sibling, 1 reply; 24+ messages in thread From: Andrew Cooper @ 2017-05-14 15:39 UTC (permalink / raw) To: pgnet.dev, Valentin Vidic Cc: Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On 14/05/17 00:17, PGNet Dev wrote: > On 5/13/17 3:15 PM, Valentin Vidic wrote: >> Try booting without 'hpet=force,verbose clocksource=hpet' and it should >> select xen by default: > 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? 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-14 15:39 ` Andrew Cooper @ 2017-05-14 17:41 ` Randy Dunlap 0 siblings, 0 replies; 24+ messages in thread From: Randy Dunlap @ 2017-05-14 17:41 UTC (permalink / raw) To: Andrew Cooper, pgnet.dev, Valentin Vidic Cc: linux-kernel, Clemens Ladisch, xen-devel On 05/14/17 08:39, Andrew Cooper wrote: > On 14/05/17 00:17, PGNet Dev wrote: >> On 5/13/17 3:15 PM, Valentin Vidic wrote: >>> Try booting without 'hpet=force,verbose clocksource=hpet' and it should >>> select xen by default: >> 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? > > 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? > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 23:17 ` PGNet Dev 2017-05-14 15:39 ` Andrew Cooper @ 2017-05-15 18:06 ` Austin S. Hemmelgarn 2017-05-17 0:12 ` PGNet Dev 2017-05-17 0:15 ` PGNet Dev 1 sibling, 2 replies; 24+ messages in thread From: Austin S. Hemmelgarn @ 2017-05-15 18:06 UTC (permalink / raw) To: pgnet.dev, Valentin Vidic Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel On 2017-05-13 19:17, PGNet Dev wrote: > On 5/13/17 3:15 PM, Valentin Vidic wrote: >> Try booting without 'hpet=force,verbose clocksource=hpet' and it should >> select xen by default: > > 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? 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-15 18:06 ` Austin S. Hemmelgarn @ 2017-05-17 0:12 ` PGNet Dev 2017-05-17 0:15 ` PGNet Dev 1 sibling, 0 replies; 24+ messages in thread From: PGNet Dev @ 2017-05-17 0:12 UTC (permalink / raw) To: Austin S. Hemmelgarn, Valentin Vidic Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-15 18:06 ` Austin S. Hemmelgarn 2017-05-17 0:12 ` PGNet Dev @ 2017-05-17 0:15 ` PGNet Dev 1 sibling, 0 replies; 24+ messages in thread From: PGNet Dev @ 2017-05-17 0:15 UTC (permalink / raw) To: Austin S. Hemmelgarn, Valentin Vidic Cc: Andrew Cooper, Randy Dunlap, linux-kernel, Clemens Ladisch, xen-devel (apologies re: the empty 'double tap' :-/ ) On 5/14/17 8:39 AM, Andrew Cooper wrote: >> 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. ... " ?? OTOH, this comment: On 5/15/17 11:06 AM, Austin S. Hemmelgarn wrote: > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 17:41 ` Randy Dunlap 2017-05-13 18:26 ` PGNet Dev @ 2017-05-13 19:45 ` Clemens Ladisch 2017-05-13 19:52 ` PGNet Dev 1 sibling, 1 reply; 24+ messages in thread From: Clemens Ladisch @ 2017-05-13 19:45 UTC (permalink / raw) To: pgnet.dev; +Cc: Randy Dunlap, linux-kernel Randy Dunlap wrote: > On 05/12/17 19:30, PGNet Dev wrote: >> dmesg | grep -i hpet >> [ 8.491738] hpet_acpi_add: no address or irqs in _CRS > > Above line marks a big failure. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> Disassembling the firmware acpi tables >> >> cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out >> iasl -d /var/tmp/hpet.out That table is not used by hpet_acpi_add; you have to check for the device that mentions "PNP0103" in the DSDT table. But anyway, as far as I can tell from my own machine, the _CRS in the DSDT table never lists the HPET interrupts, and the HPET registration is always done by hpet_reserve_platform_timers() in arch/x86/kernel/hpet.c. Try adding logging to hpet_late_init() to find out why it aborts. Regards, Clemens ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? 2017-05-13 19:45 ` Clemens Ladisch @ 2017-05-13 19:52 ` PGNet Dev 0 siblings, 0 replies; 24+ messages in thread From: PGNet Dev @ 2017-05-13 19:52 UTC (permalink / raw) To: Clemens Ladisch; +Cc: Randy Dunlap, linux-kernel On 5/13/17 12:45 PM, Clemens Ladisch wrote: > That table is not used by hpet_acpi_add; you have to check for the device > that mentions "PNP0103" in the DSDT table. > > But anyway, as far as I can tell from my own machine, the _CRS in the > DSDT table never lists the HPET interrupts, and the HPET registration is > always done by hpet_reserve_platform_timers() in arch/x86/kernel/hpet.c. > Try adding logging to hpet_late_init() to find out why it aborts. I assume you mean in kernel source code? I'm using distro packages for both kernel & Xen -- not DIY building. ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-05-17 0:15 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-13 2:30 HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? PGNet Dev 2017-05-13 17:41 ` Randy Dunlap 2017-05-13 18:26 ` PGNet Dev 2017-05-13 19:28 ` Randy Dunlap 2017-05-13 19:38 ` [Xen-devel] " Andrew Cooper 2017-05-13 19:49 ` PGNet Dev 2017-05-13 19:59 ` Andrew Cooper 2017-05-13 20:05 ` PGNet Dev 2017-05-13 20:16 ` Andrew Cooper 2017-05-13 21:07 ` PGNet Dev 2017-05-14 17:13 ` Juergen Gross 2017-05-13 20:28 ` Valentin Vidic 2017-05-13 21:06 ` PGNet Dev 2017-05-13 21:32 ` Valentin Vidic 2017-05-13 21:58 ` PGNet Dev 2017-05-13 22:15 ` Valentin Vidic 2017-05-13 23:17 ` PGNet Dev 2017-05-14 15:39 ` Andrew Cooper 2017-05-14 17:41 ` Randy Dunlap 2017-05-15 18:06 ` Austin S. Hemmelgarn 2017-05-17 0:12 ` PGNet Dev 2017-05-17 0:15 ` PGNet Dev 2017-05-13 19:45 ` Clemens Ladisch 2017-05-13 19:52 ` PGNet Dev
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).