mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: kvm-devel@lists.sourceforge.net
Cc: Avi Kivity <avi@qumranet.com>,
	akpm@osdl.org, linux-kernel@vger.kernel.org, uril@qumranet.com
Subject: Re: [kvm-devel] [PATCH 3/3] KVM: Expose MSRs to userspace
Date: Thu, 16 Nov 2006 20:08:48 +0100	[thread overview]
Message-ID: <200611162008.48931.arnd@arndb.de> (raw)
In-Reply-To: <20061116180422.0CC9325015E@cleopatra.q>

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 <><

  reply	other threads:[~2006-11-16 19:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-16 17:59 [PATCH 0/3] KVM: Save/resume support Avi Kivity
2006-11-16 18:02 ` [PATCH 1/3] KVM: Expose interrupt bitmap Avi Kivity
2006-11-16 18:03 ` [PATCH 2/3] KVM: Add time stamp counter msr and accessors Avi Kivity
2006-11-16 18:04 ` [PATCH 3/3] KVM: Expose MSRs to userspace Avi Kivity
2006-11-16 19:08   ` Arnd Bergmann [this message]
2006-11-16 19:17     ` [kvm-devel] " Avi Kivity
2006-11-17  8:06       ` Christoph Hellwig
2006-11-17  1:02   ` Andrew Morton
2006-11-17  7:20     ` Avi Kivity
2006-11-17  8:15       ` Andrew Morton
2006-11-17  8:17         ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200611162008.48931.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@osdl.org \
    --cc=avi@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=uril@qumranet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome