linux.kernel - 26 new messages in 19 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* [PATCH] Remove bus dependency for iommu_domain_alloc. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ace715b4db0f0ed7?hl=en
* mm/nobootmem: Fix unused variable - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0793c386a238169e?hl=en
* Why is (2 < 2) true? Is it a gcc bug? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/587453bf46273e70?hl=en
* bio_integrity_verify() bug causing READ verify to be silently skipped - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/cf25ed79a5250081?hl=en
* ext4: add cross rename support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2b03f04905ff68d3?hl=en
* use ether_addr_equal_64bits - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/c126115ff68bc79d?hl=en
* nvme: Fix invalid call to irq_set_affinity_hint() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7ded004c0804c466?hl=en
* clk: sunxi: Add support for PLL6 on the A31 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/46edabf6d608fd30?hl=en
* [v3.12][v3.13][Regression] EISA: Initialize device before its resources - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/bf9255ff181e65b5?hl=en
* DT: Add vendor prefix for Emerging Display Technologies - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/f5e803719aa929d0?hl=en
* Last minute ACPI fix for v3.13 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/738628a78fd4d949?hl=en
* iMX gpio: Allow reading back of pin status if configured as gpio output - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/f34a9e40faa9372a?hl=en
* x86, CPU, AMD: Add workaround for family 16h, erratum 793 - 4 messages, 3
authors
http://groups.google.com/group/linux.kernel/t/0e4150592fc82fa1?hl=en
* More GPIO madness on iMX6 - and the crappy ARM port of Linux - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/3756c905d46867b0?hl=en
* Add mm flag to control THP - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/eff632e7496a6e85?hl=en
* net/dt: Add support for overriding phy configuration from device tree - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/136c5a0335789c2c?hl=en
* mmc: sdhci: fix possible scheduling while atomic - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5220ab2fee9bc8b4?hl=en
* i2c: New bus driver for the QUP I2C controller - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2c6bb71246961625?hl=en
* MAINTAINERS tree branches [xen tip as an example] - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e080ae587afdec2e?hl=en

==============================================================================
TOPIC: [PATCH] Remove bus dependency for iommu_domain_alloc.
http://groups.google.com/group/linux.kernel/t/ace715b4db0f0ed7?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 1:30 pm
From: Alex Williamson


On Fri, 2014-01-17 at 20:21 +0000, Varun Sethi wrote:
>
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Saturday, January 18, 2014 1:39 AM
> > To: Sethi Varun-B16395
> > Cc: joro@8bytes.org; iommu@lists.linux-foundation.org; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [RFC][PATCH] Remove bus dependency for iommu_domain_alloc.
> >
> > On Sat, 2014-01-18 at 01:00 +0530, Varun Sethi wrote:
> > > This patch attempts to remove iommu_domain_alloc function's dependency
> > on the bus type.
> > > This dependency is quiet restrictive in case of vfio, where it's
> > > possible to bind multiple iommu groups (from different bus types) to
> > the same iommu domain.
> > >
> > > This patch is based on the assumption, that there is a single iommu
> > > for all bus types on the system.
> > >
> > > We maintain a list of bus types (for which iommu ops are registered).
> > > In the iommu_domain_alloc function we ensure that all bus types
> > correspond to the same set of iommu operations.
> >
> > Seems like this just kicks the problem down the road a little ways as I
> > expect the assumption isn't going to last long. I think there's another
> > way to do this and we can do it entirely from within vfio_iommu_type1.
> > We have a problem on x86 that the IOMMU driver can be backed by multiple
> > IOMMU hardware devices. These separate devices are architecturally
> > allowed to have different properties. The property causing us trouble is
> > cache coherency. Some hardware devices allow us to use IOMMU_CACHE as a
> > mapping attribute, others do not. Therefore we cannot use a single IOMMU
> > domain to optimally handle all devices in a heterogeneous environment.
> >
> > I think the solution to this is to have vfio_iommu_type1 transparently
> > support multiple IOMMU domains. In the implementation of that, it seems
> > to make sense to move the iommu_domain_alloc() to the point where we
> > attach a group to the domain. That means we can scan the devices in the
> [Sethi Varun-B16395] Multiple iommu groups can also share the same domain (as a part
> Of the same VFIO container). I am not sure how can we handle the case of iommu groups from
> Different bus types in vfio.

Correct and believe I handle this. The difference is that rather than
attaching a new group to and old domain and hoping for the best, we now
allocate a domain for each group, attach the group to the new domain,
then compare the capabilities of the new domain to the old domain. If
we determine they are compatible, we throw away the new domain and use
the old one. If they are not compatible, for instance if they are for
different bus_types or if the cache coherence support is different, they
remain separate and we duplicate mappings to both domains. Hopefully
this is more clear in the code I just sent. Thanks,

Alex

> > domain to determine the bus. I suppose there is still an assumption that
> > all the devices in a group are on the same bus, but since the group is
> > determined by the IOMMU and we already assume only a single IOMMU per
> > bus, I think we're ok. I spent some time working on a patch to do this,
> > but it isn't quite finished. I'll try to bandage the rough edges and
> > send it out as an RFC so you can see what I'm talking about. Thanks,
> >
> > Alex
> >
> > > Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> > > ---
> > > arch/arm/mm/dma-mapping.c | 2 +-
> > > drivers/gpu/drm/msm/msm_gpu.c | 2 +-
> > > drivers/iommu/amd_iommu_v2.c | 2 +-
> > > drivers/iommu/iommu.c | 32
> > +++++++++++++++++++++++++++++---
> > > drivers/media/platform/omap3isp/isp.c | 2 +-
> > > drivers/remoteproc/remoteproc_core.c | 2 +-
> > > drivers/vfio/vfio_iommu_type1.c | 2 +-
> > > include/linux/device.h | 2 ++
> > > include/linux/iommu.h | 4 ++--
> > > virt/kvm/iommu.c | 2 +-
> > > 10 files changed, 40 insertions(+), 12 deletions(-)
>



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mm/nobootmem: Fix unused variable
http://groups.google.com/group/linux.kernel/t/0793c386a238169e?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 1:40 pm
From: Andrew Morton


On Thu, 16 Jan 2014 14:33:06 +0100 Philipp Hachtmann <phacht@linux.vnet.ibm.com> wrote:

> This fixes an unused variable warning in nobootmem.c
>
> ...
>
> --- a/mm/nobootmem.c
> +++ b/mm/nobootmem.c
> @@ -116,9 +116,13 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
> static unsigned long __init free_low_memory_core_early(void)
> {
> unsigned long count = 0;
> - phys_addr_t start, end, size;
> + phys_addr_t start, end;
> u64 i;
>
> +#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
> + phys_addr_t size;
> +