From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Heads up: More user-unaccessible x86 states? Date: Mon, 05 Oct 2009 14:05:44 +0200 Message-ID: <4AC9E118.8030304@redhat.com> References: <4AC86404.3090209@web.de> <4AC87299.4040508@redhat.com> <4AC87E08.5070908@web.de> <4AC88BF2.7080200@redhat.com> <4AC8F282.3090307@web.de> <4AC98FBC.3030509@redhat.com> <4AC9A395.5010609@web.de> <4AC9B490.5020502@redhat.com> <4AC9D608.2000205@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34447 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758503AbZJEMGN (ORCPT ); Mon, 5 Oct 2009 08:06:13 -0400 In-Reply-To: <4AC9D608.2000205@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/05/2009 01:18 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 10/05/2009 09:43 AM, Jan Kiszka wrote: >> >>> Avi Kivity wrote: >>> >>> >>>> On 10/04/2009 09:07 PM, Jan Kiszka wrote: >>>> >>>> >>>>>> btw, instead of adding a new ioctl, perhaps it makes sense to define a >>>>>> new KVM_VCPU_STATE structure that holds all current and future state >>>>>> (with generous reserved space), instead of separating state over a >>>>>> dozen >>>>>> ioctls. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> OK, makes sense. With our without lapic state? >>>>> >>>>> >>>> I'm in two minds. I'm leaning towards including lapic but would welcome >>>> arguments either way. >>>> >>>> >>> The lapic is optional and, thus, typically handled in different code >>> modules by user space. QEMU even creates a separate device that holds >>> the state. >>> >> avx registers, nested vmx are optional as well. >> >> >>> I'm not sure user space will benefit from a unified query/set >>> interface with regard to this. >>> >>> >> The main benefit is to avoid creating an ioctl each time we find a >> missing bit. >> >> >>>> Note we have to be careful with timers such as the tsc and lapic timer. >>>> Maybe have a bitmask at the front specifying which elements are active. >>>> >>>> >>> ...and the lapic timers are another argument. >>> >>> Regarding TSC, which means MSRs: I tend to include only states into the >>> this meta state which have fixed sizes. Otherwise things will get very >>> hairy. And the GET/SET_MSRS interface is already fairly flexible, the >>> question would be again: What can we gain by unifying? >>> >>> >> For MSRs, not much. >> >> Note we can make it work, by storing an offset/length at a fixed >> location and letting userspace point it into the reserved area. >> > Hmm, pointers... That makes me think of a meta IOCTL like this: > > struct kvm_vcpu_state { > int substates; > void __user *substate[0]; > }; > > True pointers are no go since we have to deal with compat code (31/32 bit userspace calling into a 64 bit kernel). Offsets into the state structure are easier. > #define KVM_VCPU_STATE_REGS 0 /* i.e. substate[0] points to kvm_regs */ > #define KVM_VCPU_STATE_SREGS 1 > #define KVM_VCPU_STATE_LAPIC 2 > ... > > We could easily extend the call with more substates just by defining new > pointer slots. Moreover, user space could define which substates should > be get/set by simply passing NULL or a valid pointer for substate[n] (or > by limiting the substates field). > > The only ugliness I see is the missing type safety as we would have to > deal with void pointers to the substate structures here. > For fixed sized state a feature bitmap is sufficient I think. -- error compiling committee.c: too many arguments to function