On Wed, Oct 30, 2019 at 5:57 PM Saravana Kannan wrote:
>
> On Wed, Oct 30, 2019 at 8:54 AM Will Deacon wrote:
> >
> > Hi Robin,
> >
> > On Wed, Oct 30, 2019 at 03:35:55PM +, Robin Murphy wrote:
> > > On 30/10/2019 14:51, Will Deacon wrote:
> > > > As part of the work to enable a "Generic Kern
On Mon, Nov 4, 2019 at 5:29 AM Robin Murphy wrote:
>
> On 04/11/2019 12:16, John Garry wrote:
> > On 01/11/2019 21:13, Saravana Kannan wrote:
> >> On Fri, Nov 1, 2019 at 3:28 AM John Garry wrote:
> >>>
> >>> On 31/10/2019 23:34, Saravana Kannan via iommu wrote:
> I looked into the iommu-map
On Mon, Nov 4, 2019 at 4:16 AM John Garry wrote:
>
> On 01/11/2019 21:13, Saravana Kannan wrote:
> > On Fri, Nov 1, 2019 at 3:28 AM John Garry wrote:
> >>
> >> On 31/10/2019 23:34, Saravana Kannan via iommu wrote:
> >>> I looked into the iommu-map property and it shouldn't be too hard to
> >>> ad
On Mon, Nov 4, 2019 at 3:43 AM Lorenzo Pieralisi
wrote:
>
> On Fri, Nov 01, 2019 at 02:26:05PM -0700, Saravana Kannan wrote:
> > On Fri, Nov 1, 2019 at 5:28 AM Lorenzo Pieralisi
> > wrote:
> > >
> > > On Fri, Nov 01, 2019 at 12:41:48PM +0100, Jean-Philippe Brucker wrote:
> > >
> > > [...]
> > >
>
Hi Shimoda-san,
Thanks for your patch,
On 2019-11-06 11:35:50 +0900, Yoshihiro Shimoda wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> this patch adds a utlb_offset_base into struct ipmmu_features
> for IMUCTR and IMUASID registers. No behavior change.
>
> Signed
Hi Shimoda-san,
Thanks for your work,
On 2019-11-06 11:35:49 +0900, Yoshihiro Shimoda wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> This patch adds helper functions ipmmu_utlb_reg() and
> ipmmu_imu{asid,ctr}_write() for "uTLB" registers. No behavior change.
>
>
Hi Shimoda-san,
Thanks for your patch,
On 2019-11-06 11:35:48 +0900, Yoshihiro Shimoda wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> this patch uses ipmmu_features values instead of a macro to
> calculate context registers offset. No behavior change.
>
> Signed
Hi Shimoda-san,
Thanks for your work,
On 2019-11-06 11:35:47 +0900, Yoshihiro Shimoda wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> This patch adds helper functions ipmmu_ctx_{reg,read,write}()
> for MMU "context" registers. No behavior change.
>
> Signed-off-b
Hi Shimoda-san,
Thanks for your patch,
On 2019-11-06 11:35:46 +0900, Yoshihiro Shimoda wrote:
> To support different registers memory mapping hardware easily
> in the future, this patch tidies up the register definitions
> as below:
> - Add comments to state to which SoCs or SoC families they ap
Hi Shimoda-san,
Thanks for your work.
On 2019-11-06 11:35:45 +0900, Yoshihiro Shimoda wrote:
> To support different registers memory mapping hardware easily
> in the future, this patch removes all unused register
> definitions.
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Niklas Söderlund
On Mon, 4 Nov 2019 19:52:26 +0800, Chao Hao wrote:
> This patch adds description for MT6779 IOMMU.
>
> MT6779 has two iommus, they are MM_IOMMU and APU_IOMMU which
> use ARM Short-Descriptor translation format.
>
> The MT6779 IOMMU hardware diagram is as below, it is only a brief
> diagram about
Hi Joerg,
Do you have any further comment on this patch?
Thanks
Yian
On 10/17/2019 4:39 AM, Yian Chen wrote:
VT-d RMRR (Reserved Memory Region Reporting) regions are reserved
for device use only and should not be part of allocable memory pool of OS.
BIOS e820_table reports complete memory ma
On Wed, Nov 06, 2019 at 04:17:40PM +0800, zhangfei wrote:
> > But I still believe it would be better to create an uacce_mm structure
> > that tracks all queues bound to this mm, and pass that to uacce_sva_exit
> > instead of the uacce_device.
> I am afraid this method may not work.
> Since currentl
On 05/11/2019 16:28, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
Hi All,
We still have DMA problems with some PCI devices. Since the PowerPC updates
4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to
work with our PCI devi
> From: Alex Williamson
> Sent: Wednesday, November 6, 2019 7:36 AM
> To: Liu, Yi L
> Subject: Re: [RFC v2 2/3] vfio/type1: VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> On Thu, 24 Oct 2019 08:26:22 -0400
> Liu Yi L wrote:
>
> > This patch adds VFIO_IOMMU_PASID_REQUEST ioctl which aims
> > to passd
The 'IOMMU_QCOM_SYS_CACHE' IOMMU protection flag is exposed to all
users of the IOMMU API. Despite its name, the idea behind it isn't
especially tied to Qualcomm implementations and could conceivably be
used by other systems.
Rename it to 'IOMMU_SYS_CACHE_ONLY' and update the comment to describe
a
On 28.10.2019 15:42, Robin Murphy wrote:
> On 24/10/2019 13:41, Laurentiu Tudor wrote:
>> From: Laurentiu Tudor
>>
>> Introduce a few new dma unmap and sync variants that, on top of the
>> original variants, return the virtual address corresponding to the
>> input dma address.
>> In order to impl
On 28.10.2019 13:38, h...@lst.de wrote:
> On Mon, Oct 28, 2019 at 10:55:05AM +, Laurentiu Tudor wrote:
@@ -85,9 +75,10 @@ static void free_rx_fd(struct dpaa2_eth_priv *priv,
sgt = vaddr + dpaa2_fd_get_offset(fd);
for (i = 1; i < DPAA2_ETH_MAX_SG_ENTRIES; i++) {
Hi, Jean
Thanks for the review.
On 2019/11/5 下午7:48, Jean-Philippe Brucker wrote:
Hi Zhangfei,
Thanks for simplifying this, it's a lot easier to review. I have some
additional comments.
On Tue, Oct 29, 2019 at 02:40:15PM +0800, Zhangfei Gao wrote:
+static int uacce_sva_exit(struct device *de
19 matches
Mail list logo
