From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [RFC PATCH] KVM: PPC: Book3S HV: add support for page faults in
 VM_IO|VM_PFNMAP vmas
Date: Mon, 12 Feb 2018 15:41:30 +0100
Message-ID: <e9a0fad0-16a8-1fff-904e-0d10a98364f0@redhat.com>
References: <20180208160303.19016-1-clg@kaod.org>
 <1518128353.2312.217.camel@kernel.crashing.org>
 <f63cbdf4-85c1-d3ac-a73d-726abdba326d@kaod.org>
 <b1fc885d-7c3a-18e4-2f48-71ec436b8953@redhat.com>
 <1518212652.2312.236.camel@kernel.crashing.org>
 <f0d6d84c-1a59-a38f-1b38-eec798236378@redhat.com>
 <1518431633.2959.9.camel@kernel.crashing.org>
 <c7468f95-f451-038f-6ddb-ca7511beabd4@redhat.com>
 <1518432889.2959.18.camel@kernel.crashing.org>
 <804f9137-c3d7-b32b-a586-ef9dc8aa26fc@redhat.com>
 <1518446319.2959.20.camel@kernel.crashing.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        =?UTF-8?Q?C=c3=a9dric_Le_Goater?= <clg@kaod.org>,
        kvm-ppc@vger.kernel.org, kvm@vger.kernel.org,
        Paul Mackerras <paulus@samba.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43164 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S933843AbeBLOli (ORCPT <rfc822;kvm@vger.kernel.org>);
        Mon, 12 Feb 2018 09:41:38 -0500
In-Reply-To: <1518446319.2959.20.camel@kernel.crashing.org>
Content-Language: en-US
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 12/02/2018 15:38, Benjamin Herrenschmidt wrote:
> On Mon, 2018-02-12 at 12:01 +0100, Paolo Bonzini wrote:
>> On 12/02/2018 11:54, Benjamin Herrenschmidt wrote:
>>> On Mon, 2018-02-12 at 11:41 +0100, Paolo Bonzini wrote:
>>>> In fact I don't know about PPC but on x86 we actually do
>>>> write-protection except on the newest processors that have a dirty page
>>>> _log_ in addition to the bits.
>>>
>>> Can you explain ? I'm not sure I got what you mean here.
>>
>> On recent processors you can get an exit to the hypervisor every time N
>> dirty pages are marked dirty, and the processor also keeps a log of
>> _which_ pages are marked dirty.  Without the log, you'd have to walk the
>> entire radix tree to find the dirty pages, which is so expensive that
>> without the log we don't use dirty bits at all.
> 
> Oh interesting. How is that log "kept" ? Some kind of HW fifo ?

Yeah, forced vmexit after 512 dirty pages, plus a pointer to the last
written entry (kept in the hypervisor->processor communication block).
Pretty clever.

Paolo