16 Nov 20:08
Re: [PATCH 3/3] KVM: Expose MSRs to userspace
From: Arnd Bergmann <arnd@...>
Subject: Re: [PATCH 3/3] KVM: Expose MSRs to userspace
Newsgroups: gmane.comp.emulators.kvm.devel, gmane.linux.kernel
Date: 2006-11-16 19:08:48 GMT
Subject: Re: [PATCH 3/3] KVM: Expose MSRs to userspace
Newsgroups: gmane.comp.emulators.kvm.devel, gmane.linux.kernel
Date: 2006-11-16 19:08:48 GMT
On Thursday 16 November 2006 19:04, Avi Kivity wrote:
> +struct kvm_msr_entry {
> + __u32 index;
> + __u32 reserved;
> + __u64 data;
> +};
> +
> +/* for KVM_GET_MSRS and KVM_SET_MSRS */
> +struct kvm_msrs {
> + __u32 vcpu;
> + __u32 nmsrs; /* number of msrs in entries */
> +
> + union {
> + struct kvm_msr_entry __user *entries;
> + __u64 padding;
> + };
> +};
ioctl interfaces with pointers in them are generally a bad idea,
though you handle most of the points against them fine here
(endianess doesn't matter, padding is correct).
Still, it might be better not to set a bad example. Is accessing
the MSRs actually performance critical? If not, you could
define the ioctl to take only a single entry argument.
A possible alternative could also be to have a variable length
argument like below, but that creates other problems:
+struct kvm_msrs {
+ __u32 vcpu;
+ __u32 nmsrs; /* number of msrs in entries */
+ struct kvm_msr_entry entries[0]; /* followed by actual msrs */
+};
This would mean that you can't tell the transfer size from the
ioctl number, but you can't do that in your code either, because
you do two separate transfers.
Arnd <><
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
RSS Feed