As per Intel vt-d spec, Rev 3.0 (section 10.4.45 "Virtual Command Response
Register"), the status code of "No PASID available" error in response to
the Allocate PASID command is 2, not 1. The same for "Invalid PASID" error
in response to the Free PASID command.
We will otherwise see confusing kern
On 2021/2/27 0:29, Jean-Philippe Brucker wrote:
> Hi Zhou,
>
> On Fri, Feb 26, 2021 at 05:43:27PM +0800, Zhou Wang wrote:
>> On 2021/2/1 19:14, Jean-Philippe Brucker wrote:
>>> Hi Zhou,
>>>
>>> On Mon, Feb 01, 2021 at 09:18:42AM +0800, Zhou Wang wrote:
> @@ -1033,8 +1076,7 @@ int arm_smmu_writ
On 2/26/21 2:44 PM, Paul Menzel wrote:
[cc: +suravee, +jörg]
Dear Alex, dear Shuah, dear Suravee, dear Jörg,
Am 03.06.20 um 08:54 schrieb Alexander Monakov:
On Tue, 2 Jun 2020, Shuah Khan wrote:
I changed the logic to read config to get max banks and counters
before checking if counters are
[cc: +suravee, +jörg]
Dear Alex, dear Shuah, dear Suravee, dear Jörg,
Am 03.06.20 um 08:54 schrieb Alexander Monakov:
On Tue, 2 Jun 2020, Shuah Khan wrote:
I changed the logic to read config to get max banks and counters
before checking if counters are writable and tried writing to all.
The
please?
>
Yes this is squashed in the snippet you are showing. The bug was
introduced in
next-20210222 and is still there when I updated to next-20210226 today.
On Fri, Feb 26, 2021 at 1:00 PM Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:
> On Fri, Feb 26, 2021 at 12:43:07P
Kernel Oops introduced in next-20210222 due to get_max_slots return arg size.
In the function find_slots() variable max_slots is zero when boundary_mask is
0x.
[0.242119] kernel BUG at ./include/linux/iommu-helper.h:30!
[0.247793] Internal error: Oops - BUG: 0 [#1] SMP
[
_slots = get_max_slots(boundary_mask);
>
> Could you double-check please?
>
>
> Yes this is squashed in the snippet you are showing. The bug was introduced
> in
> next-20210222 and is still there when I updated to next-20210226 today.
Duh! It should be fixed now f
On Fri, Feb 26, 2021 at 12:43:07PM -0800, Brad Larson wrote:
> Kernel Oops introduced in next-20210222 due to get_max_slots return arg size.
> In the function find_slots() variable max_slots is zero when boundary_mask is
> 0x.
I am looking at the stable/for-linus-5.12 and what I se
From: Thomas Gleixner
Add device specific MSI domain infrastructure for devices which have their
own resource management and interrupt chip. These devices are not related
to PCI and contrary to platform MSI they do not share a common resource and
interrupt chip. They provide their own domain spec
From: Lu Baolu
The pci_subdevice_msi_create_irq_domain() should fail if the underlying
platform is not able to support IMS (Interrupt Message Storage). Otherwise,
the isolation of interrupt is not guaranteed.
For x86, IMS is only supported on bare metal for now. We could enable it
in the virtual
Add required support in the interrupt remapping driver for devices
which generate dev-msi interrupts and use the intel remapping
domain as the parent domain. Set the source-id of all dev-msi
interrupt requests to the parent PCI device associated with it.
Reviewed-by: Tony Luck
Signed-off-by: Megh
Provide support for device specific MSI implementations for devices which
have their own resource management and interrupt chip. These devices are
not related to PCI and contrary to platform MSI they do not share a
common resource and interrupt chip. They provide their own domain specific
resource
From: Dave Jiang
Add new helpers to get the Linux IRQ number and device specific index
for given device-relative vector so that the drivers don't need to
allocate their own arrays to keep track of the vectors and hwirq for
the multi vector device MSI case.
Reviewed-by: Tony Luck
Signed-off-by:
From: Thomas Gleixner
MSI interrupts have some common flags which should be set not only for
PCI/MSI interrupts.
Move the PCI/MSI flag setting into a common function so it can be reused.
Reviewed-by: Tony Luck
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
drivers/pci/msi.c |
From: Thomas Gleixner
For devices which don't have a standard storage for MSI messages like the
upcoming IMS (Interrupt Message Store) it's required to allocate storage
space before allocating interrupts and after freeing them.
This could be achieved with the existing callbacks, but that would b
From: Thomas Gleixner
For the upcoming device MSI support it's required to have a default
irq_chip::ack implementation (irq_chip_ack_parent) so the drivers do not
need to care.
Reviewed-by: Tony Luck
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
drivers/base/platform-msi.c | 2
Generic IMS(Interrupt Message Store) irq chips and irq domain
implementations for IMS based devices which store the interrupt messages
in an array in device memory.
Allocation and freeing of interrupts happens via the generic
msi_domain_alloc/free_irqs() interface. No special purpose IMS magic
req
From: Thomas Gleixner
Until now interrupt chips which support setting affinity are not locking
the associated bus lock for two reasons:
- All chips which support affinity setting do not use buslock because they
just can operated directly on the hardware.
- All chips which use buslock do no
From: Lu Baolu
Some IOMMU specification defines some kind of hint mechanism, through
which BIOS can imply that OS runs in a virtualized environment. For
example, the caching mode defined in VT-d spec and NpCache capability
defined in the AMD IOMMU specification. This hint could also be used
outsi
Introduce a new function pointer in the irq_chip structure(irq_set_auxdata)
which is responsible for updating data which is stored in a shared register
or data storage. For example, the idxd driver uses the auxiliary data API
to enable/set and disable PASID field that is in the IMS entry (introduce
From: Thomas Gleixner
Rename it to x86_msi_prepare() and handle the allocation type setup
depending on the device type.
Add a new arch_msi_prepare define which will be utilized by the upcoming
device MSI support. Define it to NULL if not provided by an architecture
in the generic MSI header.
On
From: Thomas Gleixner
For the upcoming device MSI support a new allocation type is
required.
Reviewed-by: Tony Luck
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
arch/x86/include/asm/hw_irq.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/hw_irq.h b/ar
On Fri, Feb 26, 2021 at 11:48:13AM -0700, Jordan Crouse wrote:
> On Fri, Feb 26, 2021 at 11:24:52AM -0600, Bjorn Andersson wrote:
> > On Fri 26 Feb 03:55 CST 2021, Sai Prakash Ranjan wrote:
> >
> > > Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> > > both implement "arm,mmu-500"
On Fri 26 Feb 12:23 CST 2021, Rob Clark wrote:
> On Fri, Feb 26, 2021 at 9:24 AM Bjorn Andersson
> wrote:
> >
> > On Fri 26 Feb 03:55 CST 2021, Sai Prakash Ranjan wrote:
> >
> > > Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> > > both implement "arm,mmu-500" in some QTI SoCs a
On Fri, Feb 26, 2021 at 11:24:52AM -0600, Bjorn Andersson wrote:
> On Fri 26 Feb 03:55 CST 2021, Sai Prakash Ranjan wrote:
>
> > Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> > both implement "arm,mmu-500" in some QTI SoCs and to run through
> > adreno smmu specific implementat
On Fri, Feb 26, 2021 at 9:24 AM Bjorn Andersson
wrote:
>
> On Fri 26 Feb 03:55 CST 2021, Sai Prakash Ranjan wrote:
>
> > Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> > both implement "arm,mmu-500" in some QTI SoCs and to run through
> > adreno smmu specific implementation such
On Fri 26 Feb 03:55 CST 2021, Sai Prakash Ranjan wrote:
> Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> both implement "arm,mmu-500" in some QTI SoCs and to run through
> adreno smmu specific implementation such as enabling split pagetables
> support, we need to match the "qcom
Hi Zhou,
On Fri, Feb 26, 2021 at 05:43:27PM +0800, Zhou Wang wrote:
> On 2021/2/1 19:14, Jean-Philippe Brucker wrote:
> > Hi Zhou,
> >
> > On Mon, Feb 01, 2021 at 09:18:42AM +0800, Zhou Wang wrote:
> >>> @@ -1033,8 +1076,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_domain
> >>> *smmu_domain,
On Fri, Feb 26, 2021 at 03:25:40PM +0530, Sai Prakash Ranjan wrote:
> Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> both implement "arm,mmu-500" in some QTI SoCs and to run through
> adreno smmu specific implementation such as enabling split pagetables
> support, we need to matc
Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
both implement "arm,mmu-500" in some QTI SoCs and to run through
adreno smmu specific implementation such as enabling split pagetables
support, we need to match the "qcom,adreno-smmu" compatible first
before apss smmu or else we will b
Add compatible for SC7280 SMMU to use the Qualcomm Technologies, Inc.
specific implementation.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/ar
Patch 1 adds the sc7280 smmu compatible.
Patch 2 moves the adreno smmu check before apss smmu to enable
adreno smmu specific implementation.
Changes in v2:
* Add a comment to make sure this order is not changed in future (Jordan)
Sai Prakash Ranjan (2):
iommu/arm-smmu-qcom: Add SC7280 SMMU com
On 2021/2/1 19:14, Jean-Philippe Brucker wrote:
> Hi Zhou,
>
> On Mon, Feb 01, 2021 at 09:18:42AM +0800, Zhou Wang wrote:
>>> @@ -1033,8 +1076,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_domain
>>> *smmu_domain, int ssid,
>>> FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid) |
>>>
On Fri, Feb 26, 2021 at 1:17 PM Christoph Hellwig wrote:
>
> On Fri, Feb 26, 2021 at 12:17:50PM +0800, Claire Chang wrote:
> > Do you think I should fix this and rebase on the latest linux-next
> > now? I wonder if there are more factor and clean up coming and I
> > should wait after that.
>
> Her
Hi all,
> From: Heiko Thiery, Sent: Thursday, February 25, 2021 10:01 PM
> Am Do., 25. Feb. 2021 um 12:50 Uhr schrieb Thierry Reding:
> > On Thu, Feb 25, 2021 at 11:14:57AM +, Robin Murphy wrote:
> > > On 2021-02-25 11:09, Thierry Reding wrote:
> > > > On Wed, Feb 24, 2021 at 10:39:42PM +0100,
On 2021-02-25 23:36, Jordan Crouse wrote:
On Thu, Feb 25, 2021 at 03:54:10PM +0530, Sai Prakash Ranjan wrote:
Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
both implement "arm,mmu-500" in some QTI SoCs and to run through
adreno smmu specific implementation such as enabling spli
36 matches
Mail list logo
