From: Laszlo Ersek <lersek@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PULL 08/10] target/arm: Conditionalize some asserts on aarch32 support
Date: Thu, 18 Jul 2019 21:07:32 +0200 [thread overview]
Message-ID: <3f443103-782f-736d-f72a-a3e148d21aef@redhat.com> (raw)
In-Reply-To: <CAFEAcA_jasrCne5=iLGuciJmf9FSQTduQD8xfnzbES6527mbgQ@mail.gmail.com>
On 07/18/19 14:30, Peter Maydell wrote:
> On Wed, 17 Jul 2019 at 16:08, Laszlo Ersek <lersek@redhat.com> wrote:
>>
>> On 07/17/19 15:46, Peter Maydell wrote:
>>> On Wed, 17 Jul 2019 at 14:36, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>>>> I still wonder why this didn't assert on Peter's setup.
>>>
>>> My setup does not assert because my host kernel correctly
>>> provides the ID register values to QEMU. Laszlo's appears
>>> to be providing all-zeroes, which then obviously breaks
>>> assertions being made about the sanity of those ID register
>>> values...
>>
>> OK. Can you suggest a location that I should check in the host kernel?
>
> I was about to write out the process of how we get these values
> from the kernel, but as the first step of that I read through
> QEMU's target/arm/kvm64.c:kvm_arm_get_host_cpu_features(),
> which is the function which reads these values using the
> KVM_GET_ONE_REG ioctl. It starts with an attempt to read
> ID_AA64PFR0, and has a comment for the error-handling case:
>
> /*
> * Before v4.15, the kernel only exposed a limited number of system
> * registers, not including any of the interesting AArch64 ID regs.
> * For the most part we could leave these fields as zero with minimal
> * effect, since this does not affect the values seen by the guest.
> *
> * However, it could cause problems down the line for QEMU,
> * so provide a minimal v8.0 default.
> *
> * ??? Could read MIDR and use knowledge from cpu64.c.
> * ??? Could map a page of memory into our temp guest and
> * run the tiniest of hand-crafted kernels to extract
> * the values seen by the guest.
> * ??? Either of these sounds like too much effort just
> * to work around running a modern host kernel.
> */
>
> I have 4.15, and don't hit this assert; you have 4.14 and do,
> so I think you're going to be going through this codepath which
> currently sets only ahcf->isar.id_aa64pfr0 and none of the other
> ID register fields in the isar struct.
>
> I'm not sure exactly which kernel commits added the ID register
> reading support. (The relevant kernel code is in
> arch/arm64/kvm/sys_regs.c I think.)
I compared that file between the downstream kernel source and upstream v4.15, and it looks like the following series (indeed released as part of v4.15) is what's missing down-stream, for this particular use case:
1 27e64b4be4b8 regset: Add support for dynamically sized regsets
2 94ef7ecbdf6f arm64: fpsimd: Correctly annotate exception helpers called from asm
3 abf73988a7c2 arm64: signal: Verify extra data is user-readable in sys_rt_sigreturn
4 93390c0a1b20 arm64: KVM: Hide unsupported AArch64 CPU features from guests
5 b472db6cf8c6 arm64: efi: Add missing Kconfig dependency on KERNEL_MODE_NEON
6 38b9aeb32fa7 arm64: Port deprecated instruction emulation to new sysctl interface
7 9cf5b54fafed arm64: fpsimd: Simplify uses of {set,clear}_ti_thread_flag()
8 672365649cca arm64/sve: System register and exception syndrome definitions
9 1fc5dce78ad1 arm64/sve: Low-level SVE architectural state manipulation functions
10 ddd25ad1fde8 arm64/sve: Kconfig update and conditional compilation support
11 d0b8cd318788 arm64/sve: Signal frame and context structure definition
12 22043a3c082a arm64/sve: Low-level CPU setup
13 bc0ee4760364 arm64/sve: Core task context handling
14 79ab047c75d6 arm64/sve: Support vector length resetting for new processes
15 8cd969d28fd2 arm64/sve: Signal handling support
16 7582e22038a2 arm64/sve: Backend logic for setting the vector length
17 8f1eec57cdcc arm64: cpufeature: Move sys_caps_initialised declarations
18 2e0f2478ea37 arm64/sve: Probe SVE capabilities and usable vector lengths
19 1bd3f93641ec arm64/sve: Preserve SVE registers around kernel-mode NEON use
20 fdfa976cae5c arm64/sve: Preserve SVE registers around EFI runtime service calls
21 43d4da2c45b2 arm64/sve: ptrace and ELF coredump support
22 2d2123bc7c7f arm64/sve: Add prctl controls for userspace vector length management
23 4ffa09a939ab arm64/sve: Add sysctl to set the default vector length for new processes
24 17eed27b02da arm64/sve: KVM: Prevent guests from using SVE
25 aac45ffd1f8e arm64/sve: KVM: Treat guest SVE use as undefined instruction execution
26 07d79fe7c223 arm64/sve: KVM: Hide SVE from CPU features exposed to guests
27 43994d824e84 arm64/sve: Detect SVE and activate runtime support
28 ce6990813f15 arm64/sve: Add documentation
The differences found by the simple "diff" that I mention above are mainly due to commit #4 (93390c0a1b20, "arm64: KVM: Hide unsupported AArch64 CPU features from guests", 2017-11-03).
I found a (likely non-final) version of the cover letter too, here: https://www.spinics.net/lists/arm-kernel/msg599528.html
I guess I should convince myself to install RHEL8 on the Mustang sometime...
Thanks!
Laszlo
> Anyway, I think we need to do at least one of:
> * enhance the "provide a minimal v8.0 default" code in this
> condition in kvm_arm_get_host_cpu_features() so that it
> populates the ID registers sufficiently to avoid asserts
> and other bad things
> * make the asserts on ID register oddnesses be only for TCG
> (ie where QEMU controls the values) and not for KVM
>
> thanks
> -- PMM
>
next prev parent reply other threads:[~2019-07-18 19:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-02 17:16 [Qemu-devel] [PULL v3 00/10] target-arm queue Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 01/10] hw/arm/virt: Set VIRT_COMPAT_3_0 compat Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 02/10] hw/char: Implement nRF51 SoC UART Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 03/10] hw/arm/nrf51_soc: Connect UART to nRF51 SoC Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 04/10] tests/boot-serial-test: Add microbit board testcase Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 05/10] MAINTAINERS: Remove bouncing email in ARM ACPI Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 06/10] strongarm: mask off high[31:28] bits from dir and state registers Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 07/10] hw/arm/xilinx_zynq: Use the ARRAY_SIZE macro Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 08/10] target/arm: Conditionalize some asserts on aarch32 support Peter Maydell
2019-05-24 12:33 ` Laszlo Ersek
2019-05-24 12:45 ` Laszlo Ersek
2019-05-24 13:11 ` Philippe Mathieu-Daudé
2019-07-16 12:03 ` Peter Maydell
2019-07-16 14:02 ` Richard Henderson
2019-07-16 14:18 ` Peter Maydell
2019-07-16 15:04 ` Richard Henderson
2019-07-16 16:50 ` Laszlo Ersek
2019-07-16 16:59 ` Peter Maydell
2019-07-16 18:42 ` Laszlo Ersek
2019-07-16 20:10 ` Philippe Mathieu-Daudé
2019-07-17 8:36 ` Laszlo Ersek
2019-07-17 9:22 ` Laszlo Ersek
2019-07-17 9:24 ` Laszlo Ersek
2019-07-17 12:49 ` Laszlo Ersek
2019-07-17 12:53 ` Laszlo Ersek
2019-07-17 13:36 ` Philippe Mathieu-Daudé
2019-07-17 13:46 ` Peter Maydell
2019-07-17 15:08 ` Laszlo Ersek
2019-07-18 12:30 ` Peter Maydell
2019-07-18 19:07 ` Laszlo Ersek [this message]
2019-07-17 13:45 ` Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 09/10] hw/arm: versal: Add a model of Xilinx Versal SoC Peter Maydell
2018-11-02 17:16 ` [Qemu-devel] [PULL 10/10] hw/arm: versal: Add a virtual Xilinx Versal board Peter Maydell
2018-12-04 10:28 ` Peter Maydell
2018-12-12 22:05 ` Edgar E. Iglesias
2022-01-27 13:10 ` Peter Maydell
2022-01-30 10:33 ` Edgar E. Iglesias
2018-11-02 18:22 ` [Qemu-devel] [PULL v3 00/10] target-arm queue Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f443103-782f-736d-f72a-a3e148d21aef@redhat.com \
--to=lersek@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).