| Message ID | 20200213073630.2125-1-fangying1@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: Add the cpufreq device to show cpufreq info to guest | expand |
Patchew URL: https://patchew.org/QEMU/20200213073630.2125-1-fangying1@huawei.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===
Using expected file 'tests/data/acpi/virt/DSDT'
acpi-test: Warning! DSDT binary file mismatch. Actual [aml:/tmp/aml-SWR9F0], Expected [aml:tests/data/acpi/virt/DSDT].
to see ASL diff between mismatched files install IASL, rebuild QEMU from scratch and re-run tests with V=1 environment variable set**
ERROR:/tmp/qemu-test/src/tests/qtest/bios-tables-test.c:490:test_acpi_asl: assertion failed: (all_tables_match)
ERROR - Bail out! ERROR:/tmp/qemu-test/src/tests/qtest/bios-tables-test.c:490:test_acpi_asl: assertion failed: (all_tables_match)
make: *** [check-qtest-aarch64] Error 1
make: *** Waiting for unfinished jobs....
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=66a8dfa4a91642e38c77cdc7d2e5fc0c', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-bzlhgmky/src/docker-src.2020-02-13-02.56.43.27075:/var/tmp/qemu:z,ro', 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=66a8dfa4a91642e38c77cdc7d2e5fc0c
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-bzlhgmky/src'
make: *** [docker-run-test-quick@centos7] Error 2
real 11m15.564s
user 0m8.311s
The full log is available at
http://patchew.org/logs/20200213073630.2125-1-fangying1@huawei.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
On Thu, Feb 13, 2020 at 03:36:26PM +0800, Ying Fang wrote: > On ARM64 platform, cpu frequency is retrieved via ACPI CPPC. > A virtual cpufreq device based on ACPI CPPC is created to > present cpu frequency info to the guest. > > The default frequency is set to host cpu nominal frequency, > which is obtained from the host CPPC sysfs. Other performance > data are set to the same value, since we don't support guest > performance scaling here. > > Performance counters are also not emulated and they simply > return 1 if read, and guest should fallback to use desired > performance value as the current performance. > > Guest kernel version above 4.18 is required to make it work. > This is v2 of the series, but I don't see a changelog. Can you please describe the motivation for this? If I understand correctly, all of this is just to inform the guest of the host's CPU0 nominal or max (if nominal isn't present?) frequency. Why do that? What happens if the guest migrates somewhere where the frequency is different? If this is for a special use case, then why not come up with a different channel (guest agent?) to pass this information? Thanks, drew
On 2020/2/13 16:18, Andrew Jones wrote: > On Thu, Feb 13, 2020 at 03:36:26PM +0800, Ying Fang wrote: >> On ARM64 platform, cpu frequency is retrieved via ACPI CPPC. >> A virtual cpufreq device based on ACPI CPPC is created to >> present cpu frequency info to the guest. >> >> The default frequency is set to host cpu nominal frequency, >> which is obtained from the host CPPC sysfs. Other performance >> data are set to the same value, since we don't support guest >> performance scaling here. >> >> Performance counters are also not emulated and they simply >> return 1 if read, and guest should fallback to use desired >> performance value as the current performance. >> >> Guest kernel version above 4.18 is required to make it work. >> > > This is v2 of the series, but I don't see a changelog. > Hi Andrew, please forgive my carelessness, I forget to add the changelog here. Actually v2 is slightly modified with a few fixes for compilation warning and a commit message. > Can you please describe the motivation for this? If I understand > correctly, all of this is just to inform the guest of the host's > CPU0 nominal or max (if nominal isn't present?) frequency. Why > do that? Yes, you are right. The motivation is that there seems no other formal way than the CPPC feature for arm64 to present cpu frequency info to the OS. However on x86 platform we have the CPUID method to do that. Some of our VM customers and cloud developers want that information to do something. So we come up with the virtual cpufreq device way. > What happens if the guest migrates somewhere where the > frequency is different? If the guest is migrated to any host where the frequency is different, a next read on the CPPC related register may return the new cpufreq info. > If this is for a special use case, then > why not come up with a different channel (guest agent?) to pass > this information? Maybe some userspace apps need it to do perf tuning or they want to know the accurate cpu nominal frequency by using tools like lshw. We use the CPPC cpufreq way because we think this is a much more standard way to do that. > > Thanks, > drew > > > . > Thanks， Ying