From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages Date: Fri, 26 Jul 2013 17:27:00 -0500 Message-ID: <1374877620.30721.32@snotra> References: <20130725085042.GJ16400@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Alexander Graf , Bhushan Bharat-R65777 , =?UTF-8?b?4oCcdGllanVuLmNoZW7igJ0=?= , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org list" , Wood Scott-B07421 , Paolo Bonzini , To: Gleb Natapov Return-path: In-Reply-To: <20130725085042.GJ16400@redhat.com> (from gleb@redhat.com on Thu Jul 25 03:50:42 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 07/25/2013 03:50:42 AM, Gleb Natapov wrote: > Why ppc uses page_is_ram() for mmap? How should I know? But looking at > the function it does it only as a fallback if > ppc_md.phys_mem_access_prot() is not provided. Making access to MMIO > noncached as a safe fallback makes sense. There's only one current implementation of ppc_md.phys_mem_access_prot(), which is pci_phys_mem_access_prot(), which also uses page_is_ram(). If page_is_ram() returns false then it checks for write-combining PCI. But yes, we would want to call ppc_md.phys_mem_access_prot() if present. Copying from the host PTE would be ideal if doesn't come with a noticeable performance impact compared to other methods, but one way or another we want to be sure we match. > It is also make sense to allow noncached access to reserved ram > sometimes. Perhaps, but that's not KVM's decision to make. You should get the same result as if you mmaped it -- because QEMU already did and we need to be consistent. Not to mention the large page kernel mapping that will have been done on e500... -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "MSIT Machine Auth CA 2" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 294462C0129 for ; Sat, 27 Jul 2013 08:27:11 +1000 (EST) Date: Fri, 26 Jul 2013 17:27:00 -0500 From: Scott Wood Subject: Re: [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages To: Gleb Natapov In-Reply-To: <20130725085042.GJ16400@redhat.com> (from gleb@redhat.com on Thu Jul 25 03:50:42 2013) Message-ID: <1374877620.30721.32@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Cc: Wood Scott-B07421 , "kvm@vger.kernel.org list" , Alexander Graf , "kvm-ppc@vger.kernel.org" , =?UTF-8?b?4oCcdGllanVuLmNoZW7igJ0=?= , Bhushan Bharat-R65777 , Paolo Bonzini , linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 07/25/2013 03:50:42 AM, Gleb Natapov wrote: > Why ppc uses page_is_ram() for mmap? How should I know? But looking at > the function it does it only as a fallback if > ppc_md.phys_mem_access_prot() is not provided. Making access to MMIO > noncached as a safe fallback makes sense. There's only one current implementation of =20 ppc_md.phys_mem_access_prot(), which is pci_phys_mem_access_prot(), =20 which also uses page_is_ram(). If page_is_ram() returns false then it =20 checks for write-combining PCI. But yes, we would want to call =20 ppc_md.phys_mem_access_prot() if present. Copying from the host PTE would be ideal if doesn't come with a =20 noticeable performance impact compared to other methods, but one way or =20 another we want to be sure we match. > It is also make sense to allow noncached access to reserved ram =20 > sometimes. Perhaps, but that's not KVM's decision to make. You should get the =20 same result as if you mmaped it -- because QEMU already did and we need =20 to be consistent. Not to mention the large page kernel mapping that =20 will have been done on e500... -Scott= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 26 Jul 2013 22:27:00 +0000 Subject: Re: [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages Message-Id: <1374877620.30721.32@snotra> List-Id: References: <20130725085042.GJ16400@redhat.com> In-Reply-To: <20130725085042.GJ16400@redhat.com> (from gleb@redhat.com on Thu Jul 25 03:50:42 2013) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Gleb Natapov Cc: Alexander Graf , Bhushan Bharat-R65777 , =?UTF-8?b?4oCcdGllanVuLmNoZW7igJ0=?= , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org list" , Wood Scott-B07421 , Paolo Bonzini , linuxppc-dev@lists.ozlabs.org On 07/25/2013 03:50:42 AM, Gleb Natapov wrote: > Why ppc uses page_is_ram() for mmap? How should I know? But looking at > the function it does it only as a fallback if > ppc_md.phys_mem_access_prot() is not provided. Making access to MMIO > noncached as a safe fallback makes sense. There's only one current implementation of ppc_md.phys_mem_access_prot(), which is pci_phys_mem_access_prot(), which also uses page_is_ram(). If page_is_ram() returns false then it checks for write-combining PCI. But yes, we would want to call ppc_md.phys_mem_access_prot() if present. Copying from the host PTE would be ideal if doesn't come with a noticeable performance impact compared to other methods, but one way or another we want to be sure we match. > It is also make sense to allow noncached access to reserved ram > sometimes. Perhaps, but that's not KVM's decision to make. You should get the same result as if you mmaped it -- because QEMU already did and we need to be consistent. Not to mention the large page kernel mapping that will have been done on e500... -Scott