On 20.12.2011, at 17:16, Christian Borntraeger wrote:
> On 20/12/11 15:20, Alexander Graf wrote:
>>> +Reads special registers from the vcpu which are not covered by sregs.
>>> +
>>> +/* s390x */
>>> +struct kvm_sregs2 {
>>> + __u64 ckc; /* clock comparator */
>>> + __u64 cputm; /* cpu timer */
>>> + __u64 gbea; /* guest breaking event address */
>>> + __u32 todpr; /* tod programmable field */
>>> + __u32 prefix; /* prefix register */
>>> +};
>>
>> Would it make sense to instead use the GET_ONE_REG and SET_ONE_REG
>> interfaces?
>>
>> http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/80854
>
> Still not sure if I like that interface or not, but it should work.
> I have some questions, though
>
> - how should userspace check if the kernel supports this specific register?
It would try to get/set it and get the respective return value.
> - How would a GET_MANY_REGS / SET_MANY_REGS look like?
struct many_regs {
__u64 nr_regs; (array length for the latter two)
__u64 ids_ptr; (ptr to user space memory with an array where we store ids
we request)
__u64 ret_ptr; (ptr to user space memory with an array where we store
return values)
__u64 reg_ptr; (ptr to user space memory with an array where the registers
are)
}
for (i = 0; i < nr_regs; i++) {
u32 __user *ret;
u64 __user *ids;
struct one_reg __user *reg;
struct one_reg tmp_reg;
int size;
size = do_normal_one_reg(get_user(&ids[i]), &tmp_reg);
if (size < 0)
return size;
copy_reg(®[i], &tmp_reg, size);
return 0;
}
Something like this maybe. We could also combine the 3 pointers into a single
struct and just have the user pass an array of that struct to kernel space.
> - Is the interface limited to 56 registers? (see the ID)
Uh. It's limited to 0x0fffffffffffffff registers per architecture :).
> - scalability and performance. I dont know about other platforms, but the
> exit overhead on s390 is in the same order of magnitute as a system call
> overhead, so multiple ioctls on the exit path will make the exit overhead
> noticably more expensive (probably can be solved by a MANY variant). This
> might be a micro optimization though.
> (actually the only register that bothers me regarding performance right now
> is prefix. qemu will need the content if it has to write to the prefix page.
> Would be good to have an interface to get that without doing another system
> call)
Do you expect the prefix register to be synced often? If so, then you should
maybe put it into kvm_struct
and always have it shared between kernel and user space, always updating it on
every user space exit
and entry (you can optimize by checking if it changed).
I don't think user space should worry about prefix too often though. Unless you
expect anyone to DMA
into the CPU prefix area :).
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
