Need more time to read and think about these mails. I just want to
clarify one thing: Bill has left HP, and now I inherited his works.
That's why I sent an update of his patch
https://lkml.org/lkml/2014/10/21/134
On 10/22/2014 10:47 AM, Eric W. Biederman wrote:
Bjorn Helgaas writes:
On 10/22/2014 10:47 AM, Bjorn Helgaas wrote:
[+cc Joerg, Eric, Tom, David, iommu list]
On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh wrote:
(2014/10/14 18:34), Li, ZhenHua wrote:
I tested on the latest stable version 3.17, it works well.
On 10/10/2014 03:13 PM, Li, Zhen-Hua wrote:
On a HP sy
Bjorn Helgaas writes:
> [-cc Bill, +cc Zhen-Hua, Eric, Tom, Jerry]
>
> Hi Joerg,
>
> I was looking at Zhen-Hua's recent patches, trying to figure out if I
> need to do anything with them. Resetting devices in the old kernel
> seems like a non-starter. Resetting devices in the new kernel, ...,
>
[+cc Joerg, Eric, Tom, David, iommu list]
On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh wrote:
> (2014/10/14 18:34), Li, ZhenHua wrote:
>> I tested on the latest stable version 3.17, it works well.
>>
>> On 10/10/2014 03:13 PM, Li, Zhen-Hua wrote:
>>> On a HP system with Intel vt-d supported and m
[-cc Bill, +cc Zhen-Hua, Eric, Tom, Jerry]
Hi Joerg,
I was looking at Zhen-Hua's recent patches, trying to figure out if I
need to do anything with them. Resetting devices in the old kernel
seems like a non-starter. Resetting devices in the new kernel, ...,
well, maybe. It seems ugly, and it s
Hi Joerg,
On 10/01/2014 11:07 AM, Anna, Suman wrote:
> Hi Laurent,
>
>> On Tuesday 30 September 2014 16:16:07 Suman Anna wrote:
>>> The debugfs support for OMAP IOMMU is currently implemented
>>> as a module, warranting certain OMAP-specific IOMMU API to
>>> be exported. The OMAP IOMMU, when enab
On Tue, 2014-10-21 at 18:18 +, bharat.bhus...@freescale.com wrote:
>
> > -Original Message-
> > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> > boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
> > Sent: Tuesday, October 21, 2014 10:05 PM
> > To: Antoni
> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
> Sent: Tuesday, October 21, 2014 10:05 PM
> To: Antonios Motakis
> Cc: open list:VFIO DRIVER; eric.au...@linaro.org; marc.zyng...@arm.co
On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
> The virqfd functionality that is used by VFIO_PCI to implement interrupt
> masking and unmasking via an eventfd, is generic enough and can be reused
> by another driver. Move it to a separate file in order to allow the code
> to be shared
On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
> Adds support to mask interrupts, and also for automasked interrupts.
> Level sensitive interrupts are exposed as automasked interrupts and
> are masked and disabled automatically when they fire.
>
> Signed-off-by: Antonios Motakis
> ---
On Tue, Oct 14 2014 at 02:53:29 PM, Mitchel Humpherys
wrote:
> From: Matt Wagantall
>
> It is sometimes necessary to poll a memory-mapped register until its value
> satisfies some condition. Introduce a family of convenience macros that do
> this. Tight-looping, sleeping, and timing out can all
On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
> Allow to memory map the MMIO regions of the device so userspace can
> directly access them. PIO regions are not being handled at this point.
>
> Signed-off-by: Antonios Motakis
> ---
> drivers/vfio/platform/vfio_platform_common.c | 57
On 10/21/2014 06:17 PM, Alex Williamson wrote:
> On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
>> Driver to bind to Linux platform devices, and callbacks to discover their
>> resources to be used by the main VFIO PLATFORM code.
>>
>> Signed-off-by: Antonios Motakis
>> ---
>> drivers/
On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
> This patch enables the IOCTLs VFIO_DEVICE_GET_REGION_INFO ioctl call,
> which allows the user to learn about the available MMIO resources of
> a device.
>
> Signed-off-by: Antonios Motakis
> ---
> drivers/vfio/platform/vfio_platform_co
On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
> Driver to bind to Linux platform devices, and callbacks to discover their
> resources to be used by the main VFIO PLATFORM code.
>
> Signed-off-by: Antonios Motakis
> ---
> drivers/vfio/platform/vfio_platform.c | 107
> +++
On Tue, Oct 21, 2014 at 4:37 PM, Alex Williamson
wrote:
> On Tue, 2014-10-21 at 14:40 +0200, Antonios Motakis wrote:
>> On Mon, Oct 20, 2014 at 11:13 PM, Alex Williamson
>> wrote:
>> > On Mon, 2014-10-13 at 15:09 +0200, Antonios Motakis wrote:
>> >> Some IOMMU drivers, such as the ARM SMMU driver
On Tue, 2014-10-21 at 14:40 +0200, Antonios Motakis wrote:
> On Mon, Oct 20, 2014 at 11:13 PM, Alex Williamson
> wrote:
> > On Mon, 2014-10-13 at 15:09 +0200, Antonios Motakis wrote:
> >> Some IOMMU drivers, such as the ARM SMMU driver, make available the
> >> IOMMU_NOEXEC flag, to set the page ta
On Mon, Oct 20, 2014 at 11:13 PM, Alex Williamson
wrote:
> On Mon, 2014-10-13 at 15:09 +0200, Antonios Motakis wrote:
>> Some IOMMU drivers, such as the ARM SMMU driver, make available the
>> IOMMU_NOEXEC flag, to set the page tables for a device as XN (execute never).
>> This affects devices such
On Mon, Oct 20, 2014 at 11:37 PM, Andy Lutomirski wrote:
> On Mon, Oct 13, 2014 at 6:09 AM, Antonios Motakis
> wrote:
>> We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
>> and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
>> This way the user can contr
On Mon, Oct 20, 2014 at 8:42 PM, Will Deacon wrote:
> On Mon, Oct 20, 2014 at 04:39:15PM +0100, Will Deacon wrote:
>> On Mon, Oct 13, 2014 at 02:06:15PM +0100, Antonios Motakis wrote:
>> > This patch series applies to Joerg Roedel's iommu/next branch, commit
>> > 09b5269a.
>> > It replaces the IO
On Mon, Oct 20, 2014 at 11:29 PM, Alex Williamson
wrote:
> On Mon, 2014-10-13 at 15:09 +0200, Antonios Motakis wrote:
>> We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
>> and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
>> This way the user can contro
Interfaces for when a new domain in the crashdump kernel needs some
values from the panicked kernel's context entries.
Signed-off-by: Bill Sumner
---
drivers/iommu/intel-iommu.c | 46 +
1 file changed, 46 insertions(+)
diff --git a/drivers/iommu/intel
Allow specification of the domain-id for the new domain.
This patch only adds the 'did' parameter to iommu_attach_domain()
and modifies all of its callers to specify the default value of -1
which says "no did specified, allocate a new one".
This is no functional change from current behaviour -- ju
Add structure type domain_values_entry used for kdump;
Add context functions needed for kdump.
Bill Sumner:
Original version;
Li, Zhenhua:
Changed the name of new functions, make them consistent with current
context get/set functions.
Signed-off-by: Bill Sumner
Signed-off-by: Li, Zhe
Modify the operation of the following functions when called during crash dump:
device_to_domain_id
get_domain_for_dev
init_dmars
intel_iommu_init
Signed-off-by: Bill Sumner
---
drivers/iommu/intel-iommu.c | 134 +++-
1 file changed, 121 insertions(+),
Populate it with support functions to copy iommu translation tables from
from the panicked kernel into the kdump kernel in the event of a crash.
Bill Sumner:
Original version, the creation of the data types and functions.
Li, Zhenhua:
Minor change: update the usage of context_get_* and co
The following series implements a fix for:
A kdump problem about DMA that has been discussed for a long time.
That is, when a kernel panics and boots into the kdump kernel, DMA that was
started by the panicked kernel is not stopped before the kdump kernel is booted;
and the kdump kernel disables th
27 matches
Mail list logo
