From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] get rid of mmu_only parameter in emulator_write_emulated() Date: Tue, 13 Apr 2010 10:35:53 +0300 Message-ID: <4BC41ED9.1000506@redhat.com> References: <20100413072156.GF23554@redhat.com> <4BC41C38.5080403@redhat.com> <20100413072643.GG23554@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, mtosatti@redhat.com To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27838 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212Ab0DMHfz (ORCPT ); Tue, 13 Apr 2010 03:35:55 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3D7ZtQS003272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Apr 2010 03:35:55 -0400 In-Reply-To: <20100413072643.GG23554@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/13/2010 10:26 AM, Gleb Natapov wrote: > On Tue, Apr 13, 2010 at 10:24:40AM +0300, Avi Kivity wrote: > >> On 04/13/2010 10:21 AM, Gleb Natapov wrote: >> >>> May be I am missing something here, but it seams we can call >>> kvm_mmu_pte_write() directly from emulator_cmpxchg_emulated() >>> instead of passing mmu_only down to emulator_write_emulated_onepage() >>> and call it there. >>> >>> >>> @@ -3460,7 +3444,9 @@ static int emulator_cmpxchg_emulated(unsigned long addr, >>> if (!exchanged) >>> return X86EMUL_CMPXCHG_FAILED; >>> >>> - return __emulator_write_emulated(addr, new, bytes, vcpu, true); >>> + kvm_mmu_pte_write(vcpu, gpa, new, bytes, 1); >>> + >>> + return X86EMUL_CONTINUE; >>> >>> >> The written range might cross a page boundary, which >> kvm_mmu_pte_write() is not prepared to handle. >> >> > Don't we emulate exchange as write in this case? > > if (((gpa + bytes - 1)& PAGE_MASK) != (gpa& PAGE_MASK)) > goto emul_write; > We do, but that's unrelated. We still have to invalidate potential ptes on both pages -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.