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.
