From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 14/15] KVM: Add support for enabling capabilities per-vcpu Date: Mon, 08 Mar 2010 16:21:40 +0200 Message-ID: <4B9507F4.8010204@redhat.com> 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> <4B950721.4070706@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62752 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754468Ab0CHOVp (ORCPT ); Mon, 8 Mar 2010 09:21:45 -0500 In-Reply-To: <4B950721.4070706@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 03/08/2010 04:18 PM, Alexander Graf wrote: > 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. > That's reasonable. Thanks. -- error compiling committee.c: too many arguments to function