On 12/06/2019 19:53, Jacob Pan wrote:
>>> You are right, the worst case of the spurious PS is to terminate the
>>> group prematurely. Need to know the scope of the HW damage in case
>>> of mdev where group IDs can be shared among mdevs belong to the
>>> same PF.
>>
>> But from the IOMMU fault
On Tue, Jun 18, 2019 at 9:09 PM Yong Wu wrote:
>
> On Tue, 2019-06-18 at 15:19 +0900, Tomasz Figa wrote:
> > On Mon, Jun 10, 2019 at 9:21 PM Yong Wu wrote:
> > >
> > > Normally the M4U HW connect EMI with smi. the diagram is like below:
> > > EMI
> > >|
> > >
On Sun, 9 Jun 2019 06:44:10 -0700
Jacob Pan wrote:
> struct page_response_msg needs to be defined outside CONFIG_IOMMU_API.
What was the error?
If this is a fix for an earlier patch in this series role it in there
(or put it before it). If more general we should add a fixes tag.
Jonathan
>
On Wed, Jun 12, 2019 at 06:59:38PM +0100, Jean-Philippe Brucker wrote:
> Ease future extensions of struct iommu_fault_page_request and struct
> iommu_fault_unrecoverable by adding a few bytes of padding. That way, a
> new field can be added to either of these structures by simply introducing
> a
On Mon, Jun 17, 2019 at 03:30:54PM +0200, Arnd Bergmann wrote:
> On 32-bit architectures, phys_addr_t may be different from dma_add_t,
> both smaller and bigger. This can lead to an overflow during an assignment
> that clang warns about:
>
> drivers/iommu/dma-iommu.c:230:10: error: implicit
On Sun, 9 Jun 2019 06:44:09 -0700
Jacob Pan 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
On Tue, 18 Jun 2019 15:22:20 +0100
Jean-Philippe Brucker wrote:
> On 11/06/2019 19:13, Jacob Pan wrote:
> +/**
> + * ioasid_find - Find IOASID data
> + * @set: the IOASID set
> + * @ioasid: the IOASID to find
> + * @getter: function to call on the found object
> + *
On 11/06/2019 19:13, Jacob Pan wrote:
+/**
+ * ioasid_find - Find IOASID data
+ * @set: the IOASID set
+ * @ioasid: the IOASID to find
+ * @getter: function to call on the found object
+ *
+ * The optional getter function allows to take a reference to the
On Sun, 9 Jun 2019 06:44:04 -0700
Jacob Pan wrote:
> From: Jean-Philippe Brucker
>
> Some IOMMU hardware features, for example PCI's PRI and Arm SMMU's Stall,
> enable recoverable I/O page faults. Allow IOMMU drivers to report PRI Page
> Requests and Stall events through the new fault
On 10/06/2019 14:17, Yong Wu wrote:
> In the 4GB mode, the physical address is remapped,
>
> Here is the detailed remap relationship.
> CPU PA ->HW PA
> 0x4000_ 0x1_4000_ (Add bit32)
> 0x8000_ 0x1_8000_ ...
> 0xc000_ 0x1_c000_ ...
On Sun, 9 Jun 2019 06:44:20 -0700
Jacob Pan wrote:
> When supporting guest SVA with emulated IOMMU, the guest PASID
> table is shadowed in VMM. Updates to guest vIOMMU PASID table
> will result in PASID cache flush which will be passed down to
> the host as bind guest PASID calls.
>
> For the
On Mon, Jun 17, 2019 at 09:20:27AM -0400, Qian Cai wrote:
> The linux-next commit "iommu/vt-d: Duplicate iommu_resv_region objects
> per device list" [1] left out an unused variable,
>
> drivers/iommu/intel-iommu.c: In function 'dmar_parse_one_rmrr':
> drivers/iommu/intel-iommu.c:4014:9: warning:
On Mon, Jun 03, 2019 at 10:05:19AM -0400, Qian Cai wrote:
> The commit "iommu/vt-d: Probe DMA-capable ACPI name space devices"
> introduced a compilation warning due to the "iommu" variable in
> for_each_active_iommu() but never used the for each element, i.e,
> "drhd->iommu".
>
>
On Sun, 9 Jun 2019 06:44:15 -0700
Jacob Pan wrote:
> Make use of generic IOASID code to manage PASID allocation,
> free, and lookup. Replace Intel specific code.
>
> Signed-off-by: Jacob Pan
Hi Jacob,
One question inline.
Jonathan
> ---
> drivers/iommu/intel-iommu.c | 11 +--
>
On Sun, 9 Jun 2019 06:44:17 -0700
Jacob Pan wrote:
> After each setup for PASID entry, related translation caches must be flushed.
> We can combine duplicated code into one function which is less error prone.
>
> Signed-off-by: Jacob Pan
Formatting nitpick below ;)
Otherwise it's cut and
On Sun, 9 Jun 2019 06:44:02 -0700
Jacob Pan wrote:
> 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,
> also
On Sun, 9 Jun 2019 06:44:08 -0700
Jacob Pan wrote:
> 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 6/14/19 8:44 AM, Alan Stern wrote:
On Thu, 13 Jun 2019, shuah wrote:
Great! So all we have to do is fix vhci-hcd. Then we can remove all
the virt_boundary_mask stuff from usb-storage and uas entirely.
(I'm assuming wireless USB isn't a genuine issue. As far as I know, it
is pretty much
On 09/06/2019 14:44, Jacob Pan wrote:
> Guest shared virtual address (SVA) may require host to shadow guest
> PASID tables. Guest PASID can also be allocated from the host via
> enlightened interfaces. In this case, guest needs to bind the guest
> mm, i.e. cr3 in guest physical address to the
On 10/06/2019 14:17, Yong Wu wrote:
> This patch only rename the variable name from enable_4GB to
> dram_is_4gb for readable.
>From my understanding this is true when available RAM > 4GB so I think the name
should be something like dram_bigger_4gb otherwise it may create confusion
again.
On Sun, 9 Jun 2019 06:44:19 -0700
Jacob Pan wrote:
> Use combined macro for_each_svm_dev() to simplify SVM device iteration.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Jacob Pan
> Reviewed-by: Eric Auger
> ---
> drivers/iommu/intel-svm.c | 79
>
On Sun, 9 Jun 2019 06:44:12 -0700
Jacob Pan wrote:
> From: Jean-Philippe Brucker
>
> Some devices might support multiple DMA address spaces, in particular
> those that have the PCI PASID feature. PASID (Process Address Space ID)
> allows to share process address spaces with devices (SVA),
Hi Bjorn,
On Wed, May 15, 2019 at 04:32:34PM -0700, Bjorn Andersson wrote:
> Describe the memory related to page table walks as non-cachable for iommu
> instances that are not DMA coherent.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/iommu/io-pgtable-arm.c | 12 +---
> 1 file
On Wed, Jun 12, 2019 at 12:45:51PM +0530, Vivek Gautam wrote:
> There are scnenarios where drivers are required to make a
> scm call in atomic context, such as in one of the qcom's
> arm-smmu-500 errata [1].
>
> [1] ("https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/
>
Hi Vivek,
On Fri, Jun 14, 2019 at 02:48:07PM +0530, Vivek Gautam wrote:
> On 6/14/2019 9:35 AM, Bjorn Andersson wrote:
> > On Wed 12 Jun 00:15 PDT 2019, Vivek Gautam wrote:
> >
> > > Qcom's implementation of arm,mmu-500 adds a WAIT-FOR-SAFE logic
> > > to address under-performance issues in
On Mon, Jun 10, 2019 at 07:47:09PM +0100, Jean-Philippe Brucker wrote:
> For platform devices that support SubstreamID (SSID), firmware provides
> the number of supported SSID bits. Restrict it to what the SMMU supports
> and cache it into master->ssid_bits.
>
> Signed-off-by: Jean-Philippe
There are some DMA files under the main dir. Move them to the
new chapter and add an index file for them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/PCI/pci.rst| 6 +++---
Documentation/block/biodoc.rst | 2 +-
On Tue, 18 Jun 2019, Ricardo Neri wrote:
> On Fri, Jun 14, 2019 at 05:54:05PM +0200, Thomas Gleixner wrote:
> >
> > So we already have ticks per second, aka frequency, right? So why do we
> > need yet another function instead of using the value which is computed
> > once? The frequency of the
On Tue, 18 Jun 2019, Ricardo Neri wrote:
> On Sun, Jun 16, 2019 at 11:55:03AM +0200, Thomas Gleixner wrote:
> > On Thu, 23 May 2019, Ricardo Neri wrote:
> > >
> > > struct irq_cfg {
> > > - unsigned intdest_apicid;
> > > - unsigned intvector;
> > > + unsigned int
On Tue, 18 Jun 2019 15:04:36 +0100
Jean-Philippe Brucker wrote:
> On 12/06/2019 19:53, Jacob Pan wrote:
> >>> You are right, the worst case of the spurious PS is to terminate
> >>> the group prematurely. Need to know the scope of the HW damage in
> >>> case of mdev where group IDs can be shared
On 18/06/2019 14:10, Yong Wu wrote:
> On Mon, 2019-06-17 at 18:23 +0200, Matthias Brugger wrote:
>>
>> On 10/06/2019 14:17, Yong Wu wrote:
>>> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
>>> mmu0 or mmu1 to balance the bandwidth via the smi-common register
>>>
On Sun, Jun 16, 2019 at 11:55:03AM +0200, Thomas Gleixner wrote:
> On Thu, 23 May 2019, Ricardo Neri wrote:
> >
> > struct irq_cfg {
> > - unsigned intdest_apicid;
> > - unsigned intvector;
> > + unsigned intdest_apicid;
> > + unsigned
On Fri, Jun 14, 2019 at 08:17:14PM +0200, Thomas Gleixner wrote:
> On Thu, 23 May 2019, Ricardo Neri wrote:
> > +/**
> > + * hpet_set_comparator() - Helper function for setting comparator register
> > + * @num: The timer ID
> > + * @cmp: The value to be written to the comparator/accumulator
>
On Fri, Jun 14, 2019 at 06:10:18PM +0200, Thomas Gleixner wrote:
> On Thu, 13 Jun 2019, Ricardo Neri wrote:
>
> > On Tue, Jun 11, 2019 at 09:54:25PM +0200, Thomas Gleixner wrote:
> > > On Thu, 23 May 2019, Ricardo Neri wrote:
> > >
> > > > HPET timer 2 will be used to drive the HPET-based
On Fri, Jun 14, 2019 at 05:54:05PM +0200, Thomas Gleixner wrote:
> On Thu, 23 May 2019, Ricardo Neri wrote:
> >
> > +u64 hpet_get_ticks_per_sec(u64 hpet_caps)
> > +{
> > + u64 ticks_per_sec, period;
> > +
> > + period = (hpet_caps & HPET_COUNTER_CLK_PERIOD_MASK) >>
> > +
On Tue, Jun 11, 2019 at 10:11:04PM +0200, Thomas Gleixner wrote:
> On Thu, 23 May 2019, Ricardo Neri wrote:
> > @@ -52,10 +59,10 @@ static void kick_timer(struct hpet_hld_data *hdata,
> > bool force)
> > return;
> >
> > if (hdata->has_periodic)
> > - period =
Quoting Lu Baolu (2019-05-21 08:30:15)
> From: Dave Jiang
>
> Lockdep debug reported lock inversion related with the iommu code
> caused by dmar_insert_one_dev_info() grabbing the iommu->lock and
> the device_domain_lock out of order versus the code path in
> iommu_flush_dev_iotlb(). Expanding
On Mon, Jun 17, 2019 at 10:25:35AM +0200, Thomas Gleixner wrote:
> On Sun, 16 Jun 2019, Thomas Gleixner wrote:
> > On Thu, 23 May 2019, Ricardo Neri wrote:
> > > When the hardlockup detector is enabled, the function
> > > hld_hpet_intremapactivate_irq() activates the recently created entry
> > >
On Mon, Jun 10, 2019 at 9:21 PM Yong Wu wrote:
>
> Normally the M4U HW connect EMI with smi. the diagram is like below:
> EMI
>|
> M4U
>|
> smi-common
>|
>-
>||| |
Hi, Yong:
On Mon, 2019-06-10 at 20:55 +0800, Yong Wu wrote:
> MediaTek IOMMU has already added the device_link between the consumer
> and smi-larb device. If the drm device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
>
> CC: CK Hu
> CC:
Hi Chris,
On 6/19/19 5:02 AM, Chris Wilson wrote:
Quoting Lu Baolu (2019-05-21 08:30:15)
From: Dave Jiang
Lockdep debug reported lock inversion related with the iommu code
caused by dmar_insert_one_dev_info() grabbing the iommu->lock and
the device_domain_lock out of order versus the code
On 07/06/2019 22:35, Andrew F. Davis wrote:
This patch adds a driver for the Page-based Address Translator (PAT)
present on various TI SoCs. A PAT device performs address translation
using tables stored in an internal SRAM. Each PAT supports a set number
of pages, each occupying a programmable
On Tue, 2019-06-18 at 15:19 +0900, Tomasz Figa wrote:
> On Mon, Jun 10, 2019 at 9:21 PM Yong Wu wrote:
> >
> > Normally the M4U HW connect EMI with smi. the diagram is like below:
> > EMI
> >|
> > M4U
> >|
> > smi-common
> >
On Mon, 2019-06-17 at 18:23 +0200, Matthias Brugger wrote:
>
> On 10/06/2019 14:17, Yong Wu wrote:
> > There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
> > mmu0 or mmu1 to balance the bandwidth via the smi-common register
> > SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
> >
On Tue, 2019-06-18 at 14:35 +0800, CK Hu wrote:
> Hi, Yong:
>
> On Mon, 2019-06-10 at 20:55 +0800, Yong Wu wrote:
> > MediaTek IOMMU has already added the device_link between the consumer
> > and smi-larb device. If the drm device call the pm_runtime_get_sync,
> > the smi-larb's
On 10/06/2019 14:17, Yong Wu wrote:
> The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
> It's no need to parse it again in SMI driver. Only clean some codes.
> This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
> and mt8183.
>
> After this patch, the
46 matches
Mail list logo
