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 09:43:17 +0200 Message-ID: <4AC9A395.5010609@web.de> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF7C8581359271CBD0B26F015" Cc: kvm-devel To: Avi Kivity Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:46858 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754001AbZJEHn7 (ORCPT ); Mon, 5 Oct 2009 03:43:59 -0400 In-Reply-To: <4AC98FBC.3030509@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF7C8581359271CBD0B26F015 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 do= zen >>> ioctls. >>> >>> =20 >> OK, makes sense. With our without lapic state? >=20 > I'm in two minds. I'm leaning towards including lapic but would welcom= e > 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. I'm not sure user space will benefit from a unified query/set interface with regard to this. >=20 > Note we have to be careful with timers such as the tsc and lapic timer.= =20 > Maybe have a bitmask at the front specifying which elements are active.= =2E..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? >=20 >> How much "future space"? >> =20 >=20 > 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. >=20 Hmm, a some kB then (even without MSRs)... Jan --------------enigF7C8581359271CBD0B26F015 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkrJo5kACgkQitSsb3rl5xSyCgCg13FwvoisirkAMBwlziL2UCeX DegAoLoJjKrQShLzA5XRiKeajMsZ/5mS =un1p -----END PGP SIGNATURE----- --------------enigF7C8581359271CBD0B26F015--