Re: [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04.09.2012, at 09:31, Peter Maydell wrote:

> On 1 September 2012 13:28, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
>> Rusty Russell (8):
>>      KVM: ARM: Fix walk_msrs()
>>      KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code.
>>      KVM: Add KVM_REG_SIZE() helper.
>>      KVM: ARM: use KVM_SET_ONE_REG/KVM_GET_ONE_REG.
>>      KVM: Add KVM_VCPU_GET_REG_LIST.
>>      KVM: ARM: Use KVM_VCPU_GET_REG_LIST.
>>      KVM: ARM: Access all registers via KVM_GET_ONE_REG/KVM_SET_ONE_REG.
>>      KVM ARM: Update api.txt
> 
> So I was thinking about this, and I remembered that the SET_ONE_REG/
> GET_ONE_REG API has userspace pass a pointer to the variable the
> kernel should read/write (unlike the _MSR x86 ioctls, where the
> actual data value is sent back and forth in the struct). Further,
> the kernel only writes a data value of the size of the register
> (rather than always reading/writing a uint64_t).
> 
> This is a problem because it means userspace needs to know the
> size of each register, and the kernel doesn't provide any way
> to determine the size.

It does, as it's encoded in the register ID.

> This defeats the idea that userspace should
> be able to migrate kernel register state without having to know
> the semantics of all the registers involved.
> 
> Possible solutions:
> * switch GET/SET_ONE_REG to just passing data, same as the MSR ioctls
> * switch GET/SET_ONE_REG to always writing 64 bits regardless of
>   actual guest register width
> * make GET_REG_LIST return register width as well as index
> 
> Personally I would really prefer the MSR-style "pass the data".

Well, the reason I put dynamic sizes in there is that we already have very big register sizes on x86 (265 bits iirc), and so far chances are that it'll rather get bigger than smaller over time. So I would really like to keep the size encoding in the register id so that we can support big multimedia registers later on.

> Otherwise I'm going to end up constructing something like
> uint64_t actual_values[]
> struct kvm_one_reg regs[]
> 
> where regs[x].addr = &actual_values[x] for all x. Which seems
> like unnecessary indirection really :-)
> 
> I could live with "always read/write 64 bits". I definitely don't
> want to have to deal with matching up register widths to accesses
> in userspace, please.

If I understood Rusty correctly, he wanted to do exactly that. Just make all the ARM registers be 64-bit wide, so that you can just keep them all as uint64_t in QEMU's env and then put env's pointers into the ONE_REG ioctl.


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux