From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzAHZ-0005fI-KA for qemu-devel@nongnu.org; Wed, 18 Nov 2015 16:28:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzAHW-0000no-CZ for qemu-devel@nongnu.org; Wed, 18 Nov 2015 16:28:49 -0500 Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:35651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzAHW-0000ni-6N for qemu-devel@nongnu.org; Wed, 18 Nov 2015 16:28:46 -0500 Received: by wmdw130 with SMTP id w130so216284109wmd.0 for ; Wed, 18 Nov 2015 13:28:45 -0800 (PST) Sender: Paolo Bonzini References: <1447813217-10532-1-git-send-email-huaitong.han@intel.com> <20151118175159.GJ20436@thinpad.lan.raisama.net> From: Paolo Bonzini Message-ID: <564CED89.40504@redhat.com> Date: Wed, 18 Nov 2015 22:28:41 +0100 MIME-Version: 1.0 In-Reply-To: <20151118175159.GJ20436@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 0/3] target-i386: add memory protection-key support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Huaitong Han Cc: qemu-devel@nongnu.org, afaerber@suse.de, kvm@vger.kernel.org, rth@twiddle.net On 18/11/2015 18:51, Eduardo Habkost wrote: > Is every CPU supporting PKU guaranteed to have > CPUID.(EAX=0DH,ECX=9):EBX = 0xa80? We asked Intel a while ago when reorganizing XSAVE support in KVM and QEMU. Unfortunately, Intel is not listing the offsets anymore in the documentation, but they confirmed at the time that offsets won't change. http://lists.xen.org/archives/html/xen-devel/2013-09/msg00484.html is pretty clear in this respect: >> [adding H. Peter Anvin... the context is whether the layout of the >> XSAVE/XRSTOR area is fixed, including the offset of each separate >> Ext_SAVE_Area]. > > It is. > >> So please Intel, pretty please do not modify the XSAVE offsets, and >> clarify this as soon as possible. > > They will not change. > > -hpa This of course doesn't mean that the 0xa80 is correct; it only means that if it is correct, it will always stay correct. :) It makes sense that 0xa80 is correct, since ECX=8 is a supervisor state (thus never saved by XSAVE/XSAVEOPT). The fact that standard format does not account for supervisor states means that supporting supervisor states in KVM might encounter a few small complications. In particular we might have to modify KVM and QEMU to support compacted format in KVM_GET/SET_XSAVE. For now the only supervisor state is just a bunch of MSRs, so it would not be necessary to include it in KVM_GET/SET_XSAVE. Problem averted for now, then. > Where is the PKRU state offset/layout documented? Volume 1 of the SDM, section 13.5.7 ("PKRU State") documents the layout. (Careful: chapter 13 of volume 1 is "Managing State Using the XSAVE Feature Set"; chapter 13 of volume 3 is "System Programming for Instruction Set Extensions and Processor Extended States", and also deals with XSAVE). Paolo