qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]