From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH 14/15] KVM: Add support for enabling capabilities per-vcpu Date: Mon, 08 Mar 2010 15:18:09 +0100 Message-ID: <4B950721.4070706@suse.de> References: <1267807842-3751-1-git-send-email-agraf@suse.de> <1267807842-3751-15-git-send-email-agraf@suse.de> <4B950057.1090204@redhat.com> <4B9500D1.2060008@suse.de> <4B95012B.3030505@redhat.com> <4B950211.5010505@suse.de> <4B950382.8010609@redhat.com> <4B950562.6050509@suse.de> <4B950656.4010307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Avi Kivity Return-path: In-Reply-To: <4B950656.4010307-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: kvm.vger.kernel.org Avi Kivity wrote: > On 03/08/2010 04:10 PM, Alexander Graf wrote: >> >>> When we have reserved fields which are later used for something new, >>> the kernel needs a way to know if the reserved fields are known or not >>> by userspace. One way to do this is to assume a value of zero means >>> the field is unknown to usespace so ignore it. Another is to require >>> userspace to set a bit in an already-known flags field, and only act >>> on the new field if its bit was set. This has the advantage that the >>> old kernel checks for unknown flags and errors out, improving forwards >>> and backwards compatibility. >>> >>> I thought ->cap was already a bit field, so this isn't necessary, but >>> if it isn't, then a flags field is helpful. >>> >> -> cap is the capability number. So you want something like: >> >> struct kvm_enable_cap { >> __u32 cap; >> __u32 flags; >> __u64 args[4]; >> __u8 pad[64]; >> }; >> >> And then check for flags == 0 in the ioctl handler? Flags could later on >> define if the padding changed to a different position, adding new fields >> in between args and pad? >> > > Exactly, we do so in several places. Can be useful if, for example, > some new capability comes with a resource count value. > > What's this thing anyway? like cpuid bits for x86? What thing? This ioctl or the OSI call? The ioctl is a way to enable a feature on a per-vcpu basis. MOL overlays the syscall interface with a hypercall interface, so a normal OS syscall magically becomes a hypercall when magic constants get passed in r3 and r4. Because for obvious reasons we don't want to enable that when not using MOL, I figured I'd go in and have userspace decide if it wants to get a hypercall exit or not. Qemu couldn't really do anything with it after all. And while at it, I figured let's better make the interface generic. Alex