From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: qemu-kvm.git unittest failures Date: Sat, 03 Jul 2010 13:25:58 +0300 Message-ID: <4C2F1036.6030406@redhat.com> References: <1278001551.2659.308.camel@freedom> <20100702224424.GA6731@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lucas Meneghel Rodrigues , KVM mailing list , qemu mailing list , Michael Goldish , Jes Sorensen , Dor Laor , Eduardo Habkost To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56222 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754782Ab0GCK0F (ORCPT ); Sat, 3 Jul 2010 06:26:05 -0400 In-Reply-To: <20100702224424.GA6731@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 07/03/2010 01:44 AM, Marcelo Tosatti wrote: > >> Config entry: >> >> [access] >> file = access.flat >> >> Massive log, compressed and attached. >> > run > test pde.p user: FAIL: error code 5 expected 4 > test pte.rw pde.p user: FAIL: error code 5 expected 4 > test pte.user pde.p user: FAIL: error code 5 expected 4 > test pte.rw pte.user pde.p user: FAIL: error code 5 expected 4 > test pte.a pde.p user: FAIL: error code 5 expected 4 > test pte.rw pte.a pde.p user: FAIL: error code 5 expected 4 > test pte.user pte.a pde.p user: FAIL: error code 5 expected 4 > > P flag (bit 0). > This flag is 0 if there is no valid translation for the linear address > because the P > flag was 0 in one of the paging-structure entries used to translate that > address. > > Avi, a walk ignoring access permissions should be done to properly set > the P flag on error code. Does anybody care? > Probably not, but best to be compatible with real hardware. We could simply continue the existing walk, just set a flag indicating that it can't succeed. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58510 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUzvD-0000UW-0R for qemu-devel@nongnu.org; Sat, 03 Jul 2010 06:26:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUzvB-0007vX-MK for qemu-devel@nongnu.org; Sat, 03 Jul 2010 06:26:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59527) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUzvB-0007vJ-Ej for qemu-devel@nongnu.org; Sat, 03 Jul 2010 06:26:05 -0400 Message-ID: <4C2F1036.6030406@redhat.com> Date: Sat, 03 Jul 2010 13:25:58 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1278001551.2659.308.camel@freedom> <20100702224424.GA6731@amt.cnet> In-Reply-To: <20100702224424.GA6731@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: qemu-kvm.git unittest failures List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Lucas Meneghel Rodrigues , Eduardo Habkost , KVM mailing list , Michael Goldish , Dor Laor , qemu mailing list , Jes Sorensen On 07/03/2010 01:44 AM, Marcelo Tosatti wrote: > >> Config entry: >> >> [access] >> file = access.flat >> >> Massive log, compressed and attached. >> > run > test pde.p user: FAIL: error code 5 expected 4 > test pte.rw pde.p user: FAIL: error code 5 expected 4 > test pte.user pde.p user: FAIL: error code 5 expected 4 > test pte.rw pte.user pde.p user: FAIL: error code 5 expected 4 > test pte.a pde.p user: FAIL: error code 5 expected 4 > test pte.rw pte.a pde.p user: FAIL: error code 5 expected 4 > test pte.user pte.a pde.p user: FAIL: error code 5 expected 4 > > P flag (bit 0). > This flag is 0 if there is no valid translation for the linear address > because the P > flag was 0 in one of the paging-structure entries used to translate that > address. > > Avi, a walk ignoring access permissions should be done to properly set > the P flag on error code. Does anybody care? > Probably not, but best to be compatible with real hardware. We could simply continue the existing walk, just set a flag indicating that it can't succeed. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.