From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K.V" Date: Mon, 27 Jan 2014 15:57:19 +0000 Subject: Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect Message-Id: <87r47to1t7.fsf@linux.vnet.ibm.com> List-Id: References: <1390292129-15871-1-git-send-email-pingfank@linux.vnet.ibm.com> <8761pdk6x5.fsf@linux.vnet.ibm.com> <87wqhllnvm.fsf@linux.vnet.ibm.com> <72133741-22DA-4477-B89F-E9C978FA294F@suse.de> In-Reply-To: <72133741-22DA-4477-B89F-E9C978FA294F@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: Liu Ping Fan , linuxppc-dev@lists.ozlabs.org, kvm-ppc , kvm-devel , Ben Herrenschmidt , Paul Mackerras Alexander Graf writes: > On 27.01.2014, at 11:28, Aneesh Kumar K.V wrote: > >> Alexander Graf writes: >> >>> On 21.01.2014, at 10:42, Aneesh Kumar K.V wrote: >>> >>>> Liu Ping Fan writes: >>>> >>>>> To make sure that on host, the pages marked with _PAGE_NUMA result in a fault >>>>> when guest access them, we should force the checking when guest uses hypercall >>>>> to setup hpte. >>>>> >>>>> Signed-off-by: Liu Ping Fan >>>> >>>> Reviewed-by: Aneesh Kumar K.V >>>> >>>> When we mark pte with _PAGE_NUMA we already call mmu_notifier_invalidate_range_start and >>>> mmu_notifier_invalidate_range_end, which will mark existing guest hpte >>>> entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new >>>> guest hpte entries. This patch does that. >>> >>> So what happens next? We insert a page into the HTAB without >>> HPTE_V_VALID set, so the guest will fail to use it. If the guest does >>> an H_READ on it it will suddenly turn to V_VALID though? >> >> As per the guest the entry is valid, so yes an hread should return a >> valid entry. But in real hpte we would mark it not valid. > > Ah, yes. > >> >>> >>> I might need a crash course in the use of HPTE_V_ABSENT. >> >> When guest tries to access the address, the host will handle the fault. >> >> kvmppc_hpte_hv_fault should give more info > > Thanks for the pointer. So we fault it in lazily. Is there any > particular reason we can't do that on h_enter already? After all this > just means an additional roundtrip because the guest is pretty likely > to use the page it just entered, no? We could get wrong numa fault information if we didn't do h_enter from the right node from which we faulted. -aneesh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e28smtp01.in.ibm.com (e28smtp01.in.ibm.com [122.248.162.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 6E18C2C0078 for ; Tue, 28 Jan 2014 02:57:19 +1100 (EST) Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 27 Jan 2014 21:27:14 +0530 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id EF060394003F for ; Mon, 27 Jan 2014 21:27:09 +0530 (IST) Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0RFv7KN40501306 for ; Mon, 27 Jan 2014 21:27:07 +0530 Received: from d28av01.in.ibm.com (localhost [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s0RFv9m4018321 for ; Mon, 27 Jan 2014 21:27:09 +0530 From: "Aneesh Kumar K.V" To: Alexander Graf Subject: Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect In-Reply-To: <72133741-22DA-4477-B89F-E9C978FA294F@suse.de> References: <1390292129-15871-1-git-send-email-pingfank@linux.vnet.ibm.com> <8761pdk6x5.fsf@linux.vnet.ibm.com> <87wqhllnvm.fsf@linux.vnet.ibm.com> <72133741-22DA-4477-B89F-E9C978FA294F@suse.de> Date: Mon, 27 Jan 2014 21:27:08 +0530 Message-ID: <87r47to1t7.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Cc: kvm-devel , kvm-ppc , Paul Mackerras , Liu Ping Fan , linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Alexander Graf writes: > On 27.01.2014, at 11:28, Aneesh Kumar K.V wrote: > >> Alexander Graf writes: >> >>> On 21.01.2014, at 10:42, Aneesh Kumar K.V wrote: >>> >>>> Liu Ping Fan writes: >>>> >>>>> To make sure that on host, the pages marked with _PAGE_NUMA result in a fault >>>>> when guest access them, we should force the checking when guest uses hypercall >>>>> to setup hpte. >>>>> >>>>> Signed-off-by: Liu Ping Fan >>>> >>>> Reviewed-by: Aneesh Kumar K.V >>>> >>>> When we mark pte with _PAGE_NUMA we already call mmu_notifier_invalidate_range_start and >>>> mmu_notifier_invalidate_range_end, which will mark existing guest hpte >>>> entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new >>>> guest hpte entries. This patch does that. >>> >>> So what happens next? We insert a page into the HTAB without >>> HPTE_V_VALID set, so the guest will fail to use it. If the guest does >>> an H_READ on it it will suddenly turn to V_VALID though? >> >> As per the guest the entry is valid, so yes an hread should return a >> valid entry. But in real hpte we would mark it not valid. > > Ah, yes. > >> >>> >>> I might need a crash course in the use of HPTE_V_ABSENT. >> >> When guest tries to access the address, the host will handle the fault. >> >> kvmppc_hpte_hv_fault should give more info > > Thanks for the pointer. So we fault it in lazily. Is there any > particular reason we can't do that on h_enter already? After all this > just means an additional roundtrip because the guest is pretty likely > to use the page it just entered, no? We could get wrong numa fault information if we didn't do h_enter from the right node from which we faulted. -aneesh From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K.V" Subject: Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect Date: Mon, 27 Jan 2014 21:27:08 +0530 Message-ID: <87r47to1t7.fsf@linux.vnet.ibm.com> References: <1390292129-15871-1-git-send-email-pingfank@linux.vnet.ibm.com> <8761pdk6x5.fsf@linux.vnet.ibm.com> <87wqhllnvm.fsf@linux.vnet.ibm.com> <72133741-22DA-4477-B89F-E9C978FA294F@suse.de> Mime-Version: 1.0 Content-Type: text/plain Cc: Liu Ping Fan , linuxppc-dev@lists.ozlabs.org, kvm-ppc , kvm-devel , Ben Herrenschmidt , Paul Mackerras To: Alexander Graf Return-path: In-Reply-To: <72133741-22DA-4477-B89F-E9C978FA294F@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Alexander Graf writes: > On 27.01.2014, at 11:28, Aneesh Kumar K.V wrote: > >> Alexander Graf writes: >> >>> On 21.01.2014, at 10:42, Aneesh Kumar K.V wrote: >>> >>>> Liu Ping Fan writes: >>>> >>>>> To make sure that on host, the pages marked with _PAGE_NUMA result in a fault >>>>> when guest access them, we should force the checking when guest uses hypercall >>>>> to setup hpte. >>>>> >>>>> Signed-off-by: Liu Ping Fan >>>> >>>> Reviewed-by: Aneesh Kumar K.V >>>> >>>> When we mark pte with _PAGE_NUMA we already call mmu_notifier_invalidate_range_start and >>>> mmu_notifier_invalidate_range_end, which will mark existing guest hpte >>>> entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new >>>> guest hpte entries. This patch does that. >>> >>> So what happens next? We insert a page into the HTAB without >>> HPTE_V_VALID set, so the guest will fail to use it. If the guest does >>> an H_READ on it it will suddenly turn to V_VALID though? >> >> As per the guest the entry is valid, so yes an hread should return a >> valid entry. But in real hpte we would mark it not valid. > > Ah, yes. > >> >>> >>> I might need a crash course in the use of HPTE_V_ABSENT. >> >> When guest tries to access the address, the host will handle the fault. >> >> kvmppc_hpte_hv_fault should give more info > > Thanks for the pointer. So we fault it in lazily. Is there any > particular reason we can't do that on h_enter already? After all this > just means an additional roundtrip because the guest is pretty likely > to use the page it just entered, no? We could get wrong numa fault information if we didn't do h_enter from the right node from which we faulted. -aneesh