From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Heads up: More user-unaccessible x86 states? Date: Sun, 04 Oct 2009 21:07:46 +0200 Message-ID: <4AC8F282.3090307@web.de> References: <4AC86404.3090209@web.de> <4AC87299.4040508@redhat.com> <4AC87E08.5070908@web.de> <4AC88BF2.7080200@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig64E30A330AC504DB1418D010" Cc: kvm-devel To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:48747 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757725AbZJDTIY (ORCPT ); Sun, 4 Oct 2009 15:08:24 -0400 In-Reply-To: <4AC88BF2.7080200@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig64E30A330AC504DB1418D010 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 10/04/2009 12:50 PM, Jan Kiszka wrote: >> Avi Kivity wrote: >> =20 >>> On 10/04/2009 10:59 AM, Jan Kiszka wrote: >>> =20 >>>> Hi, >>>> >>>> while preparing new IOCTLs to let user space query& set the yet >>>> unaccessible NMI states (pending and masked) I also came across the >>>> interrupt shadow masks. Unless I missed something I would say that >>>> we so >>>> far break them in the rare case that a migration happens right while= >>>> any >>>> of them is asserted. So I guess I should extend my interface and stu= ff >>>> them in as well. >>>> >>>> Do we have more of such unaccessible states on x86 that could be >>>> included, too? Would be a good chance... >>>> >>>> =20 >>> There's some hidden state in the cpuid mechanism. I think we expose = it >>> though (just don't use it in qemu). >>> =20 >> Do you have more details on this? >> =20 >=20 > Some cpuid leaves return different information based on an internal > counter. This is indicated by KVM_CPUID_FLAG_STATEFUL_FUNC. >=20 >> The PDPTRs are hidden state that we should save/restore, though no san= e >> guest relies on them. >> A quick glance at SVM makes me think that those registered are not >> exposed there. So when keeping in mind that we may only help VMX guest= s, >> I think i makes even less sense to "fix" this, does it? >> =20 >=20 > Yes. With npt the PDPTRs are essentially gone. >=20 >>> I think we can lose information if we migrate during a SIPI >>> (sipi_vector), though that might be fixable without exposing it. >>> =20 >> Hmm, I see. But even it it's not fixable, such an extension would be a= n >> in-kernel irqchip thing. >> =20 >=20 > Yes. >=20 >>> We'll might also lost debug traps. >>> >>> We drop pending exceptions; normally that's fine since they'll reinje= ct >>> themselves, but MCE will not. >>> =20 >> So would it make sense and fix those two issues when we simply save an= d >> restore the pending exception? >> =20 >=20 > Yes. >=20 > 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 doze= n > ioctls. >=20 OK, makes sense. With our without lapic state? How much "future space"? Jan --------------enig64E30A330AC504DB1418D010 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 iEYEARECAAYFAkrI8oMACgkQitSsb3rl5xTS5QCg12U8ZWU2sjp3g6XCTXhYpnlw tHoAoLES92hmL0iqJVP/A9/mm3mFx43b =SZOM -----END PGP SIGNATURE----- --------------enig64E30A330AC504DB1418D010--