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 10:55:44 +0200 Message-ID: <4AC9B490.5020502@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> 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]:17582 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758705AbZJEI4M (ORCPT ); Mon, 5 Oct 2009 04:56:12 -0400 In-Reply-To: <4AC9A395.5010609@web.de> Sender: kvm-owner@vger.kernel.org List-ID: 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. >>> How much "future space"? >>> >>> >> avx will change the sse registers from 16x16 to 16x32, with a hint of >> more to come. Nested vmx needs the vmptr and some more bits. MSRs are >> potentially endless. Lots of space. >> >> > Hmm, a some kB then (even without MSRs)... > Yup, it's amazing how much state modern processors hold. -- error compiling committee.c: too many arguments to function