Re: [PATCH v3 3/4] thunderbolt: Make iommu_dma_protection more accurate

thus will end up fully protected. > > CC: Mario Limonciello > Reviewed-by: Christoph Hellwig > Signed-off-by: Robin Murphy Acked-by: Mika Westerberg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 1/2] PCI: Rename "pci_dev->untrusted" to "pci_dev->poses_dma_risk"

On Tue, Mar 22, 2022 at 01:09:55PM -0700, Rajat Jain wrote: > On Tue, Mar 22, 2022 at 4:12 AM Rafael J. Wysocki wrote: > > > > On Tue, Mar 22, 2022 at 10:02 AM Christoph Hellwig > > wrote: > > > > > > On Sat, Mar 19, 2022 at 11:29:05PM -0700, Rajat Jain wrote: > > > > Rename the field to make

Re: [PATCH v2 2/2] thunderbolt: Make iommu_dma_protection more accurate

Hi Robin, I tried this now on two Intel systems. One with integrated Thunderbolt and one with discrete. There was a small issue, see below but once fixed it worked as expected :) On Fri, Mar 18, 2022 at 05:42:58PM +, Robin Murphy wrote: > Between me trying to get rid of iommu_present() and

Re: [PATCH v4 2/2] PCI: ACPI: Support Microsoft's "DmaProperty"

r DMA attacks (e.g. internal network devices). > > Signed-off-by: Rajat Jain Reviewed-by: Mika Westerberg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 1/2] PCI: Rename "pci_dev->untrusted" to "pci_dev->poses_dma_risk"

Signed-off-by: Rajat Jain Reviewed-by: Mika Westerberg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] thunderbolt: Make iommu_dma_protection more accurate

Hi Robin, Thanks for working on this! On Thu, Mar 17, 2022 at 04:17:07PM +, Robin Murphy wrote: > Between me trying to get rid of iommu_present() and Mario wanting to > support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown > that the iommu_dma_protection attribute is being

Re: [PATCH] thunderbolt: Stop using iommu_present()

Hi Robin, On Thu, Mar 17, 2022 at 01:42:56PM +, Robin Murphy wrote: > On 2022-03-17 08:08, Mika Westerberg wrote: > > Hi Robin, > > > > On Wed, Mar 16, 2022 at 07:17:57PM +, Robin Murphy wrote: > > > The feeling I'm getting from all th

Re: [PATCH] thunderbolt: Stop using iommu_present()

Hi Robin, On Wed, Mar 16, 2022 at 07:17:57PM +, Robin Murphy wrote: > The feeling I'm getting from all this is that if we've got as far as > iommu_dma_protection_show() then it's really too late to meaningfully > mitigate bad firmware. Note, these are requirements from Microsoft in order for

Re: [PATCH] thunderbolt: Stop using iommu_present()

Hi Mario, On Wed, Mar 16, 2022 at 06:34:51PM +, Limonciello, Mario wrote: > > Might it be reasonable for the Thunderbolt core to check early on if any > > tunnelled ports are not marked as external facing, and if so just tell > > the user that iommu_dma_protection is off the table and

Re: [PATCH] thunderbolt: Stop using iommu_present()

Hi Mario, On Wed, Mar 16, 2022 at 05:24:38PM +, Limonciello, Mario wrote: > [Public] > > > On Wed, Mar 16, 2022 at 02:49:09PM +, Robin Murphy wrote: > > > > What we want is to make sure the Tunneled PCIe ports get the full > > IOMMU > > > > protection. In case of the discrete above it is

Re: [PATCH] thunderbolt: Stop using iommu_present()

Hi, On Wed, Mar 16, 2022 at 02:49:09PM +, Robin Murphy wrote: > > What we want is to make sure the Tunneled PCIe ports get the full IOMMU > > protection. In case of the discrete above it is also fine if all the > > devices behind the PCIe root port get the full IOMMU protection. Note in > >

Re: [PATCH] thunderbolt: Stop using iommu_present()

Hi Robin, On Wed, Mar 16, 2022 at 11:25:51AM +, Robin Murphy wrote: > Even if an IOMMU might be present for some PCI segment in the system, > that doesn't necessarily mean it provides translation for the device > we care about. Furthermore, the presence or not of one firmware flag > doesn't

Re: [PATCH 2/2] thunderbolt: Use pre-boot DMA protection on AMD systems

Hi, On Tue, Mar 15, 2022 at 01:36:11PM -0500, Limonciello, Mario wrote: > + Christian Kellner (Bolt userspace maintainer) > > On 3/15/2022 13:07, Robin Murphy wrote: > > On 2022-03-15 16:54, Limonciello, Mario via iommu wrote: > > > [Public] > > > > > > > > > > On Tue, Mar 15, 2022 at

Re: [PATCH 2/4] pci: set "untrusted" flag for truly external devices only

On Mon, Jun 15, 2020 at 06:17:40PM -0700, Rajat Jain wrote: > The "ExternalFacing" devices (root ports) are still internal devices > that sit on the internal system fabric and thus trusted. Currently they > were being marked untrusted - likely as an unintended border case. It was actually

Re: [PATCH 1/1] iommu/vt-d: Enable PCI ACS for platform opt in hint

/vt-d: Force IOMMU on for platform opt in hint") > Cc: Mika Westerberg Reviewed-by: Mika Westerberg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4] iommu/vt-d: Don't apply gfx quirks to untrusted devices

t the device we are applying quirks to, is > indeed an internal trusted device. > > Signed-off-by: Rajat Jain > Acked-by: Lu Baolu > Reviewed-by: Ashok Raj Looks good now, thanks! Reviewed-by: Mika Westerberg ___ iommu mailing list iommu@li

Re: [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices

On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote: > +static bool risky_device(struct pci_dev *pdev) > +{ > + if (pdev->untrusted) { > + pci_warn(pdev, > + "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted" > + " PCI link.

Re: [PATCH] iommu/vt-d: Don't apply gfx quirks to untrusted devices

On Mon, Jun 01, 2020 at 10:45:17PM -0700, Rajat Jain wrote: > Currently, an external malicious PCI device can masquerade the VID:PID > of faulty gfx devices, and thus apply iommu quirks to effectively > disable the IOMMU restrictions for itself. > > Thus we need to ensure that the device we are

Re: [PATCH v2 6/6] iommu/amd: Switch to use acpi_dev_hid_uid_match()

On Tue, Sep 24, 2019 at 10:37:39PM +0300, Andy Shevchenko wrote: > Since we have a generic helper, drop custom implementation in the driver. > > Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg ___ iommu mailing list iommu@li

Re: [PATCH v2 5/6] mmc: sdhci-acpi: Switch to use acpi_dev_hid_uid_match()

On Tue, Sep 24, 2019 at 10:37:38PM +0300, Andy Shevchenko wrote: > Since we have a generic helper, drop custom implementation in the driver. > > Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg ___ iommu mailing list iommu@li

Re: [PATCH v2 4/6] ACPI / LPSS: Switch to use acpi_dev_hid_uid_match()

On Tue, Sep 24, 2019 at 10:37:37PM +0300, Andy Shevchenko wrote: > Since we have a generic helper, drop custom implementation in the driver. > > Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg ___ iommu mailing list iommu@li

Re: [PATCH v2 3/6] ACPI / utils: Introduce acpi_dev_hid_uid_match() helper

, hid2)) > + return false; > + > + if (!uid2) > + return true; > + > + return uid1 && !strcmp(uid1, uid2); > +} > +EXPORT_SYMBOL(acpi_dev_hid_uid_match); Should this be _GPL? In any case looks good, Reviewed-by: Mika Westerberg

Re: [PATCH v2 2/6] ACPI / utils: Move acpi_dev_get_first_match_dev() under CONFIG_ACPI

> > Thus, move acpi_dev_get_first_match_dev() under CONFIG_ACPI as well. > > Fixes: 817b4d64da03 ("Introduce acpi_dev_get_first_match_dev() helper") > Reported-by: kbuild test robot > Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg _

Re: [PATCH v2 1/6] ACPI / utils: Describe function parameters in kernel-doc

le_debug' > drivers/acpi/utils.c:513: warning: Function parameter or member 'fmt' not > described in '__acpi_handle_debug' > > Describe function parameters where it's appropriate. > > Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg _

Re: [PATCH v4 0/9] iommu: Bounce page for untrusted devices

On Wed, Jun 12, 2019 at 11:00:06AM +0800, Lu Baolu wrote: > > What kind of devices did you test it with? > > Most test work was done by Xu Pengfei (cc'ed). He has run the code > on real platforms with various thunderbolt peripherals (usb, disk, > network, etc.). In addtition to that we are also

Re: [PATCH 1/4] iommu/vt-d: Disable ATS support on untrusted devices

ATS mark. As the result, IOMMU driver will block > any translated requests from any device marked as untrusted. > > Cc: Jacob Pan > Cc: Mika Westerberg Reviewed-by: Mika Westerberg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection

On Thu, Nov 29, 2018 at 06:51:49PM +0300, Mika Westerberg wrote: > Recent systems with Thunderbolt ports may be utilizing IOMMU to prevent DMA > attacks. This is different from the previous security level based scheme > because the connected device cannot access system memor

Re: [PATCH v3 1/4] PCI / ACPI: Identify untrusted PCI devices

On Mon, Dec 03, 2018 at 06:28:00PM -0600, Bjorn Helgaas wrote: > On Thu, Nov 29, 2018 at 06:51:50PM +0300, Mika Westerberg wrote: > > A malicious PCI device may use DMA to attack the system. An external > > Thunderbolt port is a convenient point to attach such a device. The OS &g

[PATCH v3 1/4] PCI / ACPI: Identify untrusted PCI devices

eat resulting when these GUIDs are treated equivalent. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports Signed-off-by: Mika Westerberg --- drivers/acpi/property.c | 11 +++ drivers/pci/pci-acpi.c | 1

[PATCH v3 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection

d not change the code with the exception of few comments and rename of the flag. Let me know if that's not the case anymore. Lu Baolu (1): iommu/vt-d: Force IOMMU on for platform opt in hint Mika Westerberg (3): PCI / ACPI: Identify untrusted PCI devices iommu/vt-d: Do not enable ATS

[PATCH v3 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace

s/security/information-protection/kernel-dma-protection-for-thunderbolt Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat --- .../ABI/testing/sysfs-bus-thunderbolt | 9 + Documentation/admin-guide/thunderbolt.rst | 20 +++ drivers/thunderbol

[PATCH v3 2/4] iommu/vt-d: Force IOMMU on for platform opt in hint

[1] https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf [2] https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt Cc: Jacob Pan Cc: Sohil Mehta Signed-off-by: Lu Baolu Signed-off-by: Mika Westerberg

Re: [PATCH v2 1/4] PCI / ACPI: Identify untrusted PCI devices

On Wed, Nov 28, 2018 at 12:24:27PM +0100, Rafael J. Wysocki wrote: > I'm not sure if this is worth the extra complexity either, which is > why I have no strong opinion here. :-) > > Maybe you can add a comment, next to the prp_guids[] definition, to > explain that the GUIDs are made equivalent to

Re: [PATCH v2 1/4] PCI / ACPI: Identify untrusted PCI devices

On Tue, Nov 27, 2018 at 06:14:43PM +0100, Rafael J. Wysocki wrote: > > diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c > > index 8c7c4583b52d..4bdad32f62c8 100644 > > --- a/drivers/acpi/property.c > > +++ b/drivers/acpi/property.c > > @@ -31,6 +31,9 @@ static const guid_t

Re: [PATCH v2 1/4] PCI / ACPI: Identify untrusted PCI devices

On Mon, Nov 26, 2018 at 06:17:11PM -0600, Bjorn Helgaas wrote: > Hi Mika, Hi, > On Mon, Nov 26, 2018 at 02:15:23PM +0300, Mika Westerberg wrote: > > Recent systems with Thunderbolt ports may support IOMMU natively. > > This sentence doesn't make sense to me. There's no

[PATCH v2 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace

s/security/information-protection/kernel-dma-protection-for-thunderbolt Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat --- .../ABI/testing/sysfs-bus-thunderbolt | 9 + Documentation/admin-guide/thunderbolt.rst | 20 +++ drivers/thunderbol

[PATCH v2 3/4] iommu/vt-d: Do not enable ATS for untrusted devices

d. In case this turns out to cause performance issues we may selectively allow ATS based on user decision but currently use big hammer and disable it completely to be on the safe side. [1] https://www.repository.cam.ac.uk/handle/1810/274352 Signed-off-by: Mika Westerberg Reviewed-by: Ashok Raj

[PATCH v2 2/4] iommu/vt-d: Force IOMMU on for platform opt in hint

. This can be turned off by adding "intel_iommu=off" in the kernel command line, if any problems are found. [1] https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt Cc: Jacob Pan Cc: Sohil Mehta Signed-off-by: Lu Baolu Signed-of

[PATCH v2 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection

Ashok, Joerg and Yehezkel. I'm assuming they still apply because I did not change the code with the exception of few comments and rename of the flag. Let me know if that's not the case anymore. Lu Baolu (1): iommu/vt-d: Force IOMMU on for platform opt in hint Mika Westerberg (3): PCI / ACP

[PATCH v2 1/4] PCI / ACPI: Identify untrusted PCI devices

rated devices and may need to put behind full IOMMU protection. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports Signed-off-by: Mika Westerberg --- drivers/acpi/property.c | 3 +++ drivers/pci/pci-acpi.c

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Fri, Nov 16, 2018 at 11:32:10AM +0200, Mika Westerberg wrote: > On Fri, Nov 16, 2018 at 01:18:04AM -0800, Christoph Hellwig wrote: > > On Thu, Nov 15, 2018 at 09:10:26PM +0200, Mika Westerberg wrote: > > > FireWire is kind of different but there are connectors such as > >

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Fri, Nov 16, 2018 at 01:18:04AM -0800, Christoph Hellwig wrote: > On Thu, Nov 15, 2018 at 09:10:26PM +0200, Mika Westerberg wrote: > > FireWire is kind of different but there are connectors such as > > ExpressCard and NVMe (over U.2 connector) which carry PCIe and are >

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Thu, Nov 15, 2018 at 09:00:54PM +0200, Mika Westerberg wrote: > On Thu, Nov 15, 2018 at 05:46:08PM +, Lorenzo Pieralisi wrote: > > Do you really need to parse it if the dev->is_thunderbolt check is enough ? > > Yes, we need to parse it one way or another. dev->is_t

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Thu, Nov 15, 2018 at 08:27:41PM +0100, Lukas Wunner wrote: > On Thu, Nov 15, 2018 at 09:10:26PM +0200, Mika Westerberg wrote: > > I was thinking we could cover all these with is_external filling them > > based on the _DSD or some other means in the kernel. > > >

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Thu, Nov 15, 2018 at 07:58:13PM +0200, Yehezkel Bernat wrote: > From what I know, there are more devices that suffer from similar security > issues like Thunderbolt, e.g. FireWire [1]. > My assumption is that the same protection may be applied to such devices too, > even if currently it sounds

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Thu, Nov 15, 2018 at 05:46:08PM +, Lorenzo Pieralisi wrote: > Do you really need to parse it if the dev->is_thunderbolt check is enough ? Yes, we need to parse it one way or another. dev->is_thunderbolt is based on heuristics which do not apply anymore when the thing gets integrated in the

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Thu, Nov 15, 2018 at 01:07:36PM +0100, Lukas Wunner wrote: > On Thu, Nov 15, 2018 at 01:37:37PM +0200, Mika Westerberg wrote: > > On Thu, Nov 15, 2018 at 11:13:56AM +, Lorenzo Pieralisi wrote: > > > I have strong objections to the way these bindings have been forced up

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Thu, Nov 15, 2018 at 11:13:56AM +, Lorenzo Pieralisi wrote: > I have strong objections to the way these bindings have been forced upon > everybody; if that's the way *generic* ACPI bindings are specified I > wonder why there still exists an ACPI specification and related working > group. >

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Tue, Nov 13, 2018 at 11:45:36AM +, Lorenzo Pieralisi wrote: > On Tue, Nov 13, 2018 at 01:27:00PM +0200, Mika Westerberg wrote: > > [...] > > > > To be frank the concept (and Microsoft _DSD bindings) seems a bit vague > > > and not thoroughly defined and

Re: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace

On Tue, Nov 13, 2018 at 05:38:53PM +0200, Yehezkel Bernat wrote: > Good point. But I thought about per-TBT-device decision. If the platform is > configured for IOMMU+"user" security level, while approving the device the > user > may want to set also in which IOMMU group to put all the PCIe

Re: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace

On Tue, Nov 13, 2018 at 04:42:58PM +0200, Yehezkel Bernat wrote: > On Tue, Nov 13, 2018 at 1:40 PM Mika Westerberg > wrote: > > > > On Tue, Nov 13, 2018 at 01:13:31PM +0200, Yehezkel Bernat wrote: > > > On Tue, Nov 13, 2018 at 12:56 PM Mika Westerberg > > >

Re: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace

On Tue, Nov 13, 2018 at 01:13:31PM +0200, Yehezkel Bernat wrote: > On Tue, Nov 13, 2018 at 12:56 PM Mika Westerberg > wrote: > > > > > Just one point: > > > Have you considered the option to add this property per (TBT?) device? > > > > No. ;-) > > &

Re: [PATCH 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection

On Tue, Nov 13, 2018 at 09:54:24AM +0100, Joerg Roedel wrote: > On Mon, Nov 12, 2018 at 07:06:24PM +0300, Mika Westerberg wrote: > > Lu Baolu (1): > > iommu/vt-d: Force IOMMU on for platform opt in hint > > > > Mika Westerberg (3): > > PCI / ACPI: Identify ex

Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices

On Tue, Nov 13, 2018 at 10:56:36AM +, Lorenzo Pieralisi wrote: > On Mon, Nov 12, 2018 at 07:02:03PM +0100, Lukas Wunner wrote: > > On Mon, Nov 12, 2018 at 07:06:25PM +0300, Mika Westerberg wrote: > > > --- a/drivers/pci/probe.c > > > +++ b/drivers/pci/probe.

Re: [PATCH 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection

On Mon, Nov 12, 2018 at 07:12:14PM +0100, Lukas Wunner wrote: > On Mon, Nov 12, 2018 at 07:06:24PM +0300, Mika Westerberg wrote: > > Recent systems shipping with Windows 10 version 1803 or newer may be > > utilizing IOMMU to prevent DMA attacks via Thunderbolt ports. This is >

Re: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace

On Mon, Nov 12, 2018 at 06:59:02PM +0200, Yehezkel Bernat wrote: > On Mon, Nov 12, 2018 at 6:06 PM Mika Westerberg > wrote: > > > > Recent systems shipping with Windows 10 version 1803 or later may > > support a feature called Kernel DMA protection [1]. In practice this &g

Re: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace

On Mon, Nov 12, 2018 at 04:22:25PM +, mario.limoncie...@dell.com wrote: > > +DMA protection utilizing IOMMU > > +-- > > +Recent systems shipping with Windows 10 version 1803 or later may support a > > +feature called `Kernel DMA Protection for Thunderbolt 3`_. This

[PATCH 2/4] iommu/vt-d: Force IOMMU on for platform opt in hint

lu Signed-off-by: Mika Westerberg --- drivers/iommu/dmar.c| 25 + drivers/iommu/intel-iommu.c | 55 +++-- include/linux/dmar.h| 8 ++ 3 files changed, 86 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/dmar.c b/drivers/io

[PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace

s/security/information-protection/kernel-dma-protection-for-thunderbolt Signed-off-by: Mika Westerberg --- .../ABI/testing/sysfs-bus-thunderbolt | 9 Documentation/admin-guide/thunderbolt.rst | 23 +++ drivers/thunderbolt/domain.c | 17 +++

[PATCH 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection

mu/vt-d: Force IOMMU on for platform opt in hint Mika Westerberg (3): PCI / ACPI: Identify external PCI devices iommu/vt-d: Do not enable ATS for external devices thunderbolt: Export IOMMU based DMA protection support to userspace .../ABI/testing/sysfs-bus-thunderbolt | 9 +++

[PATCH 1/4] PCI / ACPI: Identify external PCI devices

ivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports Signed-off-by: Mika Westerberg --- drivers/acpi/property.c | 3 +++ drivers/pci/pci-acpi.c | 13 + drivers/pci/probe.c | 23 +++ include/linux/pci.h | 1 + 4 files changed, 40 in

[PATCH 3/4] iommu/vt-d: Do not enable ATS for external devices

l. In case this turns out to cause performance issues we may selectively allow ATS based on user decision but currently use big hammer and disable it completely to be on the safe side. [1] https://www.repository.cam.ac.uk/handle/1810/274352 Signed-off-by: Mika Westerberg --- drivers/iommu/intel-i

Re: [PATCH 1/1] iommu/vt-d: Handle memory shortage on pasid table allocation

device could continue to work with only shared > virtual memory impacted. So, let's go ahead with context mapping > even the memory allocation for pasid table failed. > > Fixes: cc580e41260d ("iommu/vt-d: Per PCI device pasid table interfaces") > Cc: Ashok Raj > Cc: Jacob

Re: [PATCH 1/9] ACPI: Add support for AMBA bus type

On Fri, Dec 04, 2015 at 11:24:18AM +0800, Wang Hongcheng wrote: > From: Huang Rui > > Inspired by acpi platform bus type, to make driver "porting" more > straightforward, this patch introduces ACPI support to the AMBA bus > type. Instead of writing ACPI "glue" drivers for the