[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 11/27] arm: Allow system registers for KVM guests
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] [PULL 11/27] arm: Allow system registers for KVM guests to be changed by QEMU code |
Date: |
Thu, 21 Feb 2019 14:42:51 +0000 |
User-agent: |
mu4e 1.1.0; emacs 26.1 |
Auger Eric <address@hidden> writes:
> Hi Peter, Alex,
> On 2/14/19 8:05 PM, Peter Maydell wrote:
>> At the moment the Arm implementations of kvm_arch_{get,put}_registers()
>> don't support having QEMU change the values of system registers
>> (aka coprocessor registers for AArch32). This is because although
>> kvm_arch_get_registers() calls write_list_to_cpustate() to
>> update the CPU state struct fields (so QEMU code can read the
>> values in the usual way), kvm_arch_put_registers() does not
>> call write_cpustate_to_list(), meaning that any changes to
>> the CPU state struct fields will not be passed back to KVM.
>>
>> The rationale for this design is documented in a comment in the
>> AArch32 kvm_arch_put_registers() -- writing the values in the
>> cpregs list into the CPU state struct is "lossy" because the
>> write of a register might not succeed, and so if we blindly
>> copy the CPU state values back again we will incorrectly
>> change register values for the guest. The assumption was that
>> no QEMU code would need to write to the registers.
>>
>> However, when we implemented debug support for KVM guests, we
>> broke that assumption: the code to handle "set the guest up
>> to take a breakpoint exception" does so by updating various
>> guest registers including ESR_EL1.
>>
>> Support this by making kvm_arch_put_registers() synchronize
>> CPU state back into the list. We sync only those registers
>> where the initial write succeeds, which should be sufficient.
>>
>> Signed-off-by: Peter Maydell <address@hidden>
>> Reviewed-by: Alex Bennée <address@hidden>
>> Tested-by: Alex Bennée <address@hidden>
>> Tested-by: Dongjiu Geng <address@hidden>
> This commit introduces a regression when running with EDK2 FW:
>
> I get the following traces:
>
> error: kvm run failed Function not implemented
> PC=000000013f5a6208 X00=00000000404003c4 X01=000000000000003a
Any chance of attaching to the gdbstub and an x/10i around that PC?
--
Alex Bennée
- [Qemu-devel] [PULL 12/27] MAINTAINERS: Remove Peter Crosthwaite from various entries, (continued)
- [Qemu-devel] [PULL 12/27] MAINTAINERS: Remove Peter Crosthwaite from various entries, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 15/27] target/arm: Rely on optimization within tcg_gen_gvec_or, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 19/27] target/arm: Remove neon min/max helpers, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 14/27] hw/arm/armsse: Fix miswiring of expansion IRQs, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 13/27] hw/intc/armv7m_nvic: Allow byte accesses to SHPR1, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 11/27] arm: Allow system registers for KVM guests to be changed by QEMU code, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 22/27] target/arm: Split out flags setting from vfp compares, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 18/27] target/arm: Use tcg integer min/max primitives for neon, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 23/27] target/arm: Fix set of bits kept in xregs[ARM_VFP_FPSCR], Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 17/27] target/arm: Use vector minmax expanders for aarch32, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 21/27] target/arm: Fix arm_cpu_dump_state vs FPSCR, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 20/27] target/arm: Fix vfp_gdb_get/set_reg vs FPSCR, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 16/27] target/arm: Use vector minmax expanders for aarch64, Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 27/27] gdbstub: Send a reply to the vKill packet., Peter Maydell, 2019/02/14
- [Qemu-devel] [PULL 25/27] target/arm: Use vector operations for saturation, Peter Maydell, 2019/02/14