From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH 1/4] KVM: MMU: fix permission_fault() Date: Wed, 30 Mar 2016 14:39:05 +0800 Message-ID: <56FB7489.2080304@linux.intel.com> References: <1458911978-19430-1-git-send-email-guangrong.xiao@linux.intel.com> <56F54983.4010508@redhat.com> <56FABECE.40601@linux.intel.com> <56FAE0F3.9090809@redhat.com> <56FB3254.5070403@linux.intel.com> <56FB73E0.7060601@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, "Han, Huaitong" To: Paolo Bonzini Return-path: In-Reply-To: <56FB73E0.7060601@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 03/30/2016 02:36 PM, Paolo Bonzini wrote: > > > On 30/03/2016 03:56, Xiao Guangrong wrote: >>> x86/access.flat is currently using the "other" definition, i.e., PFEC.PK >>> is only set if W=1 or CR0.WP=0 && PFEC.U=0 or PFEC.W=0. Can you use it >>> (with ept=1 of course) to check what the processor is doing? >> >> Sure. >> >> And ept=1 is hard to trigger MMU issue, i am enabling PKEY on shadow >> MMU, let's see what will happen. ;) > > No, don't do that! > > ept=1 lets you test what the processor does. It means you cannot test > permission_fault(), but what we want here is just reverse engineering > the microcode. ept=1 lets you do exactly that. Yes, i got this point. Huaitong will do the test once the machine gets free.