From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Heads up: More user-unaccessible x86 states? Date: Mon, 05 Oct 2009 13:18:32 +0200 Message-ID: <4AC9D608.2000205@siemens.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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Avi Kivity Return-path: Received: from goliath.siemens.de ([192.35.17.28]:15858 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754474AbZJELTW (ORCPT ); Mon, 5 Oct 2009 07:19:22 -0400 In-Reply-To: <4AC9B490.5020502@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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]; }; #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. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux