All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: "Alexander Graf" <agraf@suse.de>,
	"Bhushan Bharat-R65777" <R65777@freescale.com>,
	"“tiejun.chen”" <tiejun.chen@windriver.com>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	"Wood Scott-B07421" <B07421@freescale.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages
Date: Fri, 26 Jul 2013 17:27:00 -0500	[thread overview]
Message-ID: <1374877620.30721.32@snotra> (raw)
In-Reply-To: <20130725085042.GJ16400@redhat.com> (from gleb@redhat.com on Thu Jul 25 03:50:42 2013)

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

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: "Wood Scott-B07421" <B07421@freescale.com>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	"Alexander Graf" <agraf@suse.de>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"“tiejun.chen”" <tiejun.chen@windriver.com>,
	"Bhushan Bharat-R65777" <R65777@freescale.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages
Date: Fri, 26 Jul 2013 17:27:00 -0500	[thread overview]
Message-ID: <1374877620.30721.32@snotra> (raw)
In-Reply-To: <20130725085042.GJ16400@redhat.com> (from gleb@redhat.com on Thu Jul 25 03:50:42 2013)

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=

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: "Alexander Graf" <agraf@suse.de>,
	"Bhushan Bharat-R65777" <R65777@freescale.com>,
	"“tiejun.chen”" <tiejun.chen@windriver.com>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	"Wood Scott-B07421" <B07421@freescale.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages
Date: Fri, 26 Jul 2013 22:27:00 +0000	[thread overview]
Message-ID: <1374877620.30721.32@snotra> (raw)
In-Reply-To: <20130725085042.GJ16400@redhat.com> (from gleb@redhat.com on Thu Jul 25 03:50:42 2013)

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

  parent reply	other threads:[~2013-07-26 22:27 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-18  6:04 [PATCH 1/2] kvm: powerpc: Do not ignore "E" attribute in mas2 Bharat Bhushan
2013-07-18  6:16 ` Bharat Bhushan
2013-07-18  6:04 ` [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages Bharat Bhushan
2013-07-18  6:16   ` Bharat Bhushan
2013-07-18  6:26   ` "“tiejun.chen”"
2013-07-18  6:26     ` "“tiejun.chen”"
2013-07-18  7:12     ` Bhushan Bharat-R65777
2013-07-18  7:12       ` Bhushan Bharat-R65777
2013-07-18  7:31       ` "“tiejun.chen”"
2013-07-18  7:31         ` "“tiejun.chen”"
2013-07-18  8:08         ` Bhushan Bharat-R65777
2013-07-18  8:08           ` Bhushan Bharat-R65777
2013-07-18  8:21           ` "“tiejun.chen”"
2013-07-18  8:21             ` "“tiejun.chen”"
2013-07-18  8:22             ` Bhushan Bharat-R65777
2013-07-18  8:22               ` Bhushan Bharat-R65777
2013-07-18  8:25             ` Bhushan Bharat-R65777
2013-07-18  8:25               ` Bhushan Bharat-R65777
2013-07-18  8:55               ` "“tiejun.chen”"
2013-07-18  8:55                 ` "“tiejun.chen”"
2013-07-18  9:44                 ` Alexander Graf
2013-07-18  9:44                   ` Alexander Graf
2013-07-18  9:56                   ` "“tiejun.chen”"
2013-07-18  9:56                     ` "“tiejun.chen”"
2013-07-18 10:00                     ` Alexander Graf
2013-07-18 10:00                       ` Alexander Graf
2013-07-18 10:14                       ` "“tiejun.chen”"
2013-07-18 10:14                         ` "“tiejun.chen”"
2013-07-18 16:11                       ` Scott Wood
2013-07-18 16:11                         ` Scott Wood
2013-07-18  9:48               ` Alexander Graf
2013-07-18  9:48                 ` Alexander Graf
2013-07-18  9:51                 ` Bhushan Bharat-R65777
2013-07-18 10:08                 ` "“tiejun.chen”"
2013-07-18 10:08                   ` "“tiejun.chen”"
2013-07-18 10:12                   ` Alexander Graf
2013-07-18 10:12                     ` Alexander Graf
2013-07-18 10:19                     ` "“tiejun.chen”"
2013-07-18 10:19                       ` "“tiejun.chen”"
2013-07-18 10:27                       ` Alexander Graf
2013-07-18 10:27                         ` Alexander Graf
2013-07-24  2:26                         ` "“tiejun.chen”"
2013-07-24  2:26                           ` "“tiejun.chen”"
2013-07-24  8:25                           ` Alexander Graf
2013-07-24  8:25                             ` Alexander Graf
2013-07-24  9:11                             ` Bhushan Bharat-R65777
2013-07-24  9:11                               ` Bhushan Bharat-R65777
2013-07-24  9:21                               ` Alexander Graf
2013-07-24  9:21                                 ` Alexander Graf
2013-07-24  9:35                                 ` Gleb Natapov
2013-07-24  9:35                                   ` Gleb Natapov
2013-07-24  9:39                                   ` Alexander Graf
2013-07-24  9:39                                     ` Alexander Graf
2013-07-24 20:32                                     ` Scott Wood
2013-07-24 20:32                                       ` Scott Wood
2013-07-24 20:32                                       ` Scott Wood
2013-07-25  8:50                                       ` Gleb Natapov
2013-07-25  8:50                                         ` Gleb Natapov
2013-07-25  8:50                                         ` Gleb Natapov
2013-07-25 16:07                                         ` Alexander Graf
2013-07-25 16:07                                           ` Alexander Graf
2013-07-25 16:07                                           ` Alexander Graf
2013-07-25 16:14                                           ` Gleb Natapov
2013-07-25 16:14                                             ` Gleb Natapov
2013-07-25 16:14                                             ` Gleb Natapov
2013-07-26 22:27                                         ` Scott Wood [this message]
2013-07-26 22:27                                           ` Scott Wood
2013-07-26 22:27                                           ` Scott Wood
2013-07-24 10:01                             ` Gleb Natapov
2013-07-24 10:01                               ` Gleb Natapov
2013-07-24 10:09                               ` Alexander Graf
2013-07-24 10:09                                 ` Alexander Graf
2013-07-24 10:19                                 ` Gleb Natapov
2013-07-24 10:19                                   ` Gleb Natapov
2013-07-24 10:25                                   ` Alexander Graf
2013-07-24 10:25                                     ` Alexander Graf
2013-07-24 10:30                                     ` Gleb Natapov
2013-07-24 10:30                                       ` Gleb Natapov
2013-07-25  1:04                                       ` Andrea Arcangeli
2013-07-25  1:04                                         ` Andrea Arcangeli
2013-07-18  8:27   ` "“tiejun.chen”"
2013-07-18  8:27     ` "“tiejun.chen”"

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1374877620.30721.32@snotra \
    --to=scottwood@freescale.com \
    --cc=B07421@freescale.com \
    --cc=R65777@freescale.com \
    --cc=agraf@suse.de \
    --cc=gleb@redhat.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=pbonzini@redhat.com \
    --cc=tiejun.chen@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.