On Fri, Mar 06, 2015 at 01:08:29PM -0800, Mario Smarduch wrote:
On 03/05/2015 09:43 AM, Paolo Bonzini wrote:
On 05/03/2015 15:58, Catalin Marinas wrote:
It would especially suck if the user has a cluster with different
machines, some of them coherent and others non-coherent, and then
On 04/03/2015 18:28, Catalin Marinas wrote:
Can you add that property to the device tree for PCI devices too?
Yes but not with mainline yet:
http://thread.gmane.org/gmane.linux.kernel.iommu/8935
We can add the property at the PCI host bridge level (with the drawback
that it covers
On Thu, Mar 05, 2015 at 11:12:22AM +0100, Paolo Bonzini wrote:
On 04/03/2015 18:28, Catalin Marinas wrote:
Can you add that property to the device tree for PCI devices too?
Yes but not with mainline yet:
http://thread.gmane.org/gmane.linux.kernel.iommu/8935
We can add the
On 5 March 2015 at 20:04, Catalin Marinas catalin.mari...@arm.com wrote:
On Thu, Mar 05, 2015 at 11:12:22AM +0100, Paolo Bonzini wrote:
On 04/03/2015 18:28, Catalin Marinas wrote:
Can you add that property to the device tree for PCI devices too?
Yes but not with mainline yet:
On 04/03/2015 15:29, Catalin Marinas wrote:
I disagree it is 100% a host-side issue. It is a host-side issue _if_
the host tells the guest that the (virtual) device is non-coherent (or,
more precisely, it does not explicitly tell the guest that the device is
coherent). If the guest thinks
On Wed, Mar 04, 2015 at 06:03:11PM +0100, Paolo Bonzini wrote:
On 04/03/2015 15:29, Catalin Marinas wrote:
I disagree it is 100% a host-side issue. It is a host-side issue _if_
the host tells the guest that the (virtual) device is non-coherent (or,
more precisely, it does not explicitly
On Thu, Feb 19, 2015 at 10:54:43AM +, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force the guest
to avoid uncached mappings, at least from the moment the MMU is on. (Before
that, all of memory is implicitly classified as Device-nGnRnE)
That's just
On Tue, Feb 24, 2015 at 05:47:19PM +, Ard Biesheuvel wrote:
On 24 February 2015 at 14:55, Andrew Jones drjo...@redhat.com wrote:
On Fri, Feb 20, 2015 at 04:36:26PM +0100, Andrew Jones wrote:
On Fri, Feb 20, 2015 at 02:37:25PM +, Ard Biesheuvel wrote:
On 20 February 2015 at 14:29,
On Thu, Feb 19, 2015 at 06:57:24PM +0100, Paolo Bonzini wrote:
On 19/02/2015 18:55, Andrew Jones wrote:
(I don't have an exact number for how many times it went to EL1 because
access_mair() doesn't have a trace point.)
(I got the 62873 number by testing a 3rd kernel build that
On 20 February 2015 at 14:29, Andrew Jones drjo...@redhat.com wrote:
On Thu, Feb 19, 2015 at 06:57:24PM +0100, Paolo Bonzini wrote:
On 19/02/2015 18:55, Andrew Jones wrote:
(I don't have an exact number for how many times it went to EL1
because
access_mair() doesn't have a trace
On Fri, Feb 20, 2015 at 02:37:25PM +, Ard Biesheuvel wrote:
On 20 February 2015 at 14:29, Andrew Jones drjo...@redhat.com wrote:
So looks like the 3 orders of magnitude greater number of traps
(only to el2) don't impact kernel compiles.
OK, good! That was what I was hoping for,
On 19 February 2015 at 14:50, Alexander Graf ag...@suse.de wrote:
On 19.02.15 11:54, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force the guest
to avoid uncached mappings, at least from the moment the MMU is on. (Before
that, all of memory is
On Thu, Feb 19, 2015 at 10:54:43AM +, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force the guest
to avoid uncached mappings, at least from the moment the MMU is on. (Before
that, all of memory is implicitly classified as Device-nGnRnE)
The idea
On 19/02/2015 18:55, Andrew Jones wrote:
(I don't have an exact number for how many times it went to EL1 because
access_mair() doesn't have a trace point.)
(I got the 62873 number by testing a 3rd kernel build that only had patch
3/3 applied to the base, and counting
14 matches
Mail list logo
