[spooky season is coming up, so time for some thread necromancy!]
On Thu, Jul 27 2023, Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
> On Tue, Jul 25 2023, Gavin Shan <gshan@xxxxxxxxxx> wrote:
>
>> On 7/24/23 18:48, Cornelia Huck wrote:
>>> On Mon, Jul 24 2023, Gavin Shan <gshan@xxxxxxxxxx> wrote:
>>>>
>>>> On 7/18/23 21:14, Cornelia Huck wrote:
>>>>> We can neaten the code by switching the callers that work on a
>>>>> CPUstate to the kvm_get_one_reg function.
>>>>>
>>>>> Signed-off-by: Cornelia Huck <cohuck@xxxxxxxxxx>
>>>>> ---
>>>>> target/arm/kvm.c | 15 +++---------
>>>>> target/arm/kvm64.c | 57 ++++++++++++----------------------------------
>>>>> 2 files changed, 18 insertions(+), 54 deletions(-)
>>>>>
>>>>
>>>> The replacements look good to me. However, I guess it's worty to apply
>>>> the same replacements for target/arm/kvm64.c since we're here?
>>>>
>>>> [gshan@gshan arm]$ pwd
>>>> /home/gshan/sandbox/q/target/arm
>>>> [gshan@gshan arm]$ git grep KVM_GET_ONE_REG
>>>> kvm64.c: err = ioctl(fd, KVM_GET_ONE_REG, &idreg);
>>>> kvm64.c: return ioctl(fd, KVM_GET_ONE_REG, &idreg);
>>>> kvm64.c: ret = ioctl(fdarray[2], KVM_GET_ONE_REG, ®);
>>>
>>> These are the callers that don't work on a CPUState (all in initial
>>> feature discovery IIRC), so they need to stay that way.
>>>
>>
>> Right, All these ioctl commands are issued when CPUState isn't around. However, there
>> are two wrappers read_sys_{reg32, reg64}(). The ioctl call in kvm_arm_sve_get_vls()
>> can be replaced by read_sys_reg64(). I guess it'd better to do this in a separate
>> patch if you agree.
>
> Yes, we could do that, but I'm not sure how much it adds to the
> code... in any case, I agree that this would be a separate patch.
This series has managed to bubble up to the top of my todo list again,
and I think I'll just go ahead and include that as a separate change on
top.
