Hi,
On 3/5/19 7:46 PM, James Sewart wrote:
Hey Lu,
On 5 Mar 2019, at 06:59, Lu Baolu wrote:
Hi,
It's hard for me to understand why do we remove the rmrr related
code in this patch.
The RMRR code removed here requires the lazy allocation of domains to
exist, as it is run before iommu.c
Hi,
On 3/5/19 7:14 PM, James Sewart wrote:
Hey Lu,
The motivation for this is buggy domain <-> IOMMU group relationship when
using find_or_alloc_domain. From what I have read it should be the case
that an IOMMU domain is shared by all devices in the same group, thus the
same mappings. This is
On Wed, Feb 27, 2019 at 6:33 AM Yong Wu wrote:
>
> On Mon, 2019-02-25 at 15:53 -0800, Evan Green wrote:
> > On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
> > >
> > > DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link
> > > automatically on consumer/supplier driver unbind", that means
On Wed, Feb 27, 2019 at 6:33 AM Yong Wu wrote:
>
> On Mon, 2019-02-25 at 15:54 -0800, Evan Green wrote:
> > On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
> > >
> > > Normally, If the smi-larb HW need work, we should enable the smi-common
> > > HW power and clock firstly.
> > > This patch adds
On Wed, Feb 27, 2019 at 6:33 AM Yong Wu wrote:
>
> On Mon, 2019-02-25 at 15:56 -0800, Evan Green wrote:
> > On Mon, Dec 31, 2018 at 8:53 PM Yong Wu wrote:
> > >
> > > MediaTek IOMMU should wait for smi larb which need wait for the
> > > power domain(mtk-scpsys.c) and the multimedia ccf who both
On Wed, Feb 27, 2019 at 6:34 AM Yong Wu wrote:
>
> On Mon, 2019-02-25 at 15:54 -0800, Evan Green wrote:
> > On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
> > >
> > > The iommu consumer should use device_link to connect with the
> > > smi-larb(supplier). then the smi-larb should run before the
The addresses within a single page are always contiguous, so it's
not so necessary to always allocate one single page from CMA area.
Since the CMA area has a limited predefined size of space, it may
run out of space in heavy use cases, where there might be quite a
lot CMA pages being allocated for
Hi Kevin, Yi,
On 3/5/19 4:28 PM, Jean-Philippe Brucker wrote:
> On 18/02/2019 13:54, Eric Auger wrote:
>> From: "Liu, Yi L"
>>
>> In any virtualization use case, when the first translation stage
>> is "owned" by the guest OS, the host IOMMU driver has no knowledge
>> of caching structure updates
Hi Jean,
On 3/5/19 4:23 PM, Jean-Philippe Brucker wrote:
> On 18/02/2019 13:54, Eric Auger wrote:
>> From: Jacob Pan
>>
>> In virtualization use case, when a guest is assigned
>> a PCI host device, protected by a virtual IOMMU on the guest,
>> the physical IOMMU must be programmed to be
Hi,
On 2/18/19 2:54 PM, Eric Auger wrote:
> This series allows a virtualizer to program the nested stage mode.
> This is useful when both the host and the guest are exposed with
> an SMMUv3 and a PCI device is assigned to the guest using VFIO.
>
> In this mode, the physical IOMMU must be
On 04/03/2019 18:48, Rob Herring wrote:
On Mon, Mar 4, 2019 at 11:31 AM Robin Murphy wrote:
On 04/03/2019 15:32, Rob Herring wrote:
On Fri, Mar 1, 2019 at 10:28 AM Robin Murphy wrote:
On 27/02/2019 23:22, Rob Herring wrote:
ARM Mali midgard GPU page tables are similar to standard 64-bit
On 18/02/2019 13:54, Eric Auger wrote:
> From: "Liu, Yi L"
>
> In any virtualization use case, when the first translation stage
> is "owned" by the guest OS, the host IOMMU driver has no knowledge
> of caching structure updates unless the guest invalidation activities
> are trapped by the
On 18/02/2019 13:54, Eric Auger wrote:
> From: Jacob Pan
>
> In virtualization use case, when a guest is assigned
> a PCI host device, protected by a virtual IOMMU on the guest,
> the physical IOMMU must be programmed to be consistent with
> the guest mappings. If the physical IOMMU supports two
On 18/02/2019 13:54, Eric Auger wrote:
[...]> +/**
> + * iommu_register_device_fault_handler() - Register a device fault handler
> + * @dev: the device
> + * @handler: the fault handler
> + * @data: private data passed as argument to the handler
> + *
> + * When an IOMMU fault event is received,
On 18/02/2019 13:54, Eric Auger wrote:
> From: Jacob Pan
>
> Device faults detected by IOMMU can be reported outside the IOMMU
> subsystem for further processing. This patch introduces
> a generic device fault data structure.
>
> The fault can be either an unrecoverable fault or a page request,
Hey Lu,
> On 5 Mar 2019, at 06:59, Lu Baolu wrote:
>
> Hi,
>
> It's hard for me to understand why do we remove the rmrr related
> code in this patch.
The RMRR code removed here requires the lazy allocation of domains to
exist, as it is run before iommu.c would assign IOMMU groups and attach
Hey Lu,
> On 5 Mar 2019, at 06:46, Lu Baolu wrote:
>
> Hi,
>
> On 3/4/19 11:46 PM, James Sewart wrote:
>> Allowing IOMMU_DOMAIN_DMA type IOMMU domain to be allocated allows the
>> default_domain of an iommu_group to be set. This delegates device-domain
>> relationships to the generic IOMMU
Hey Lu,
The motivation for this is buggy domain <-> IOMMU group relationship when
using find_or_alloc_domain. From what I have read it should be the case
that an IOMMU domain is shared by all devices in the same group, thus the
same mappings. This is because the IOMMU group is determined by
Hi Arnd,
On 3/5/19 8:16 AM, Arnd Bergmann wrote:
On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy wrote:
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
Hi Robin,
On 3/4/19 11:56 PM, Robin Murphy wrote:
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove
SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dma_addr_t than phys_addr_t:
In file included from
On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy wrote:
> On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
> > This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"),
> > which
> > introduced an overflow warning in configurations that have a larger
> > dma_addr_t than phys_addr_t:
> >
> >
Hi,
On 2/18/19 2:54 PM, Eric Auger wrote:
> This series allows a virtualizer to program the nested stage mode.
> This is useful when both the host and the guest are exposed with
> an SMMUv3 and a PCI device is assigned to the guest using VFIO.
>
> In this mode, the physical IOMMU must be
22 matches
Mail list logo
