[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: target/arm: "define_arm_cp_regs" and similar for KVM
From: |
Claudio Fontana |
Subject: |
Re: target/arm: "define_arm_cp_regs" and similar for KVM |
Date: |
Tue, 2 Mar 2021 13:04:07 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
On 3/2/21 1:02 PM, Peter Maydell wrote:
> On Fri, 26 Feb 2021 at 17:27, Claudio Fontana <cfontana@suse.de> wrote:
>>
>> Hi Peter,
>>
>> I am trying to find out how to split properly KVM and TCG in target/arm,
>> among other things.
>>
>> I skipped or stubbed all define_arm_cp_regs and similar functions,
>>
>> and made a cpregs module that is TCG-only.
>>
>> Thought it is fine, as we have a kvm_arm_init_cpreg_list that throws away
>> everything TCG-related anyway later:
>>
>> target/arm/kvm.c:
>>
>> /* Initialize the ARMCPU cpreg list according to the kernel's
>> * definition of what CPU registers it knows about (and throw away
>> * the previous TCG-created cpreg list).
>> */
>> int kvm_arm_init_cpreg_list(ARMCPU *cpu)
>
> It throws away the cpreg *list*, but not the cpreg hash table.
> That is, we trust KVM for "what sysregs exist and need to be migrated"
> but we still
> use the hashtable to find out what QEMU thinks about them and where it stores
> them in the CPU state structure if it knows about them. So you still
> need to keep the
> define_arm_cp_regs stuff to register sysregs. Not doing so will break
> any bits of the
> code which rely on being able to do "synchronize kernel's idea of
> sysreg state to
> QEMU" and then "read the register value out of the CPU state struct". It'll
> also
> break visibility of sysregs in the gdbstub.
>
> thanks
> -- PMM
>
Thanks for the confirmation Peter,
I ended up doing that.
Thanks,
Claudio