On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
> above the TPM hardware interface.
>
> Signed-off-by: Daniel P. Smith
> Signed-off-by: Ross Philipson
This is way, way too PoC. I
On Thu, Sep 24, 2020 at 10:58:28AM -0400, Ross Philipson wrote:
> The Trenchboot project focus on boot security has led to the enabling of
> the Linux kernel to be directly invocable by the x86 Dynamic Launch
> instruction(s) for establishing a Dynamic Root of Trust for Measurement
> (DRTM). The
This is in dma-mapping for-next now.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, Sep 21, 2020 at 09:44:18AM +0300, Tony Lindgren wrote:
> > > Looks nice to me :) I still can't test this probably for few more weeks
> > > though but hopefully Aaro or Janusz (Added to Cc) can test it.
> >
> > Works for me on Amstrad Delta (tested with a USB ethernet adapter).
> >
> >
On Tue, Sep 22, 2020 at 01:56:46PM +, David Laight wrote:
> > +/*
> > + * A dma_addr_t can hold any valid DMA or bus address for the platform.
> > It can
> > + * be given to a device to use as a DMA source or target. A CPU cannot
> > + * reference a dma_addr_t directly because there may be
On 9/24/20 7:58 AM, Ross Philipson wrote:
> Initial bits to bring in Secure Launch functionality. Add Kconfig
> options for compiling in/out the Secure Launch code.
>
> Signed-off-by: Ross Philipson
Hi,
from Documentation/process/coding-style.rst:
Lines under a ``config`` definition
are
On 9/24/20 10:08 PM, David Woodhouse wrote:
From: David Woodhouse
Instead of bailing out completely, such a unit can still be used for
interrupt remapping.
Reviewed-by: Lu Baolu
Best regards,
baolu
Signed-off-by: David Woodhouse
---
drivers/iommu/intel/dmar.c | 46
Hi Joerg,
On 9/24/20 5:55 PM, Joerg Roedel wrote:
On Tue, Sep 22, 2020 at 02:10:37PM +0800, Lu Baolu wrote:
Hi Jorge and Alex,
A description of this patch series could be found here.
https://lore.kernel.org/linux-iommu/20200901033422.22249-1-baolu...@linux.intel.com/
Hmm, I am wondering if
On Wed, Sep 23, 2020 at 12:45:11PM -0700, Rajat Jain wrote:
> On Wed, Sep 23, 2020 at 9:19 AM Raj, Ashok wrote:
> >
> > Hi Bjorn
> >
> >
> > On Wed, Sep 23, 2020 at 11:03:27AM -0500, Bjorn Helgaas wrote:
> > > [+cc IOMMU and NVMe folks]
> > >
> > > Sorry, I forgot to forward this to linux-pci
Hi Alex
> > Apparently it also requires to disable RR, and I'm not able to confirm if
> > CML requires that as well.
> >
> > pci_quirk_disable_intel_spt_pch_acs_redir() also seems to consult the same
> > table, so i'm not sure why we need the other patch in bugzilla is required.
>
> If we're
On Thu, 24 Sep 2020 11:09:05 -0700
"Raj, Ashok" wrote:
> Hi Kai
>
> + Alex, since he had some of the early quirks authored.
>
> On Thu, Sep 24, 2020 at 12:31:53AM +0800, Kai-Heng Feng wrote:
> > [+Cc Christoph]
> >
> > > On Sep 24, 2020, at 00:03, Bjorn Helgaas wrote:
> > >
> > > [+cc
IOMMU generic layer already does sanity checks on UAPI data for version
match and argsz range based on generic information.
This patch adjusts the following data checking responsibilities:
- removes the redundant version check from VT-d driver
- removes the check for vendor specific data size
-
IOMMU user APIs are responsible for processing user data. This patch
changes the interface such that user pointers can be passed into IOMMU
code directly. Separate kernel APIs without user pointers are introduced
for in-kernel users of the UAPI functionality.
IOMMU UAPI data has a user filled
IOMMU user API header was introduced to support nested DMA translation and
related fault handling. The current UAPI data structures consist of three
areas that cover the interactions between host kernel and guest:
- fault handling
- cache invalidation
- bind guest page tables, i.e. guest PASID
User APIs such as iommu_sva_unbind_gpasid() may also be used by the
kernel. Since we introduced user pointer to the UAPI functions,
in-kernel callers cannot share the same APIs. In-kernel callers are also
trusted, there is no need to validate the data.
We plan to have two flavors of the same API
IOMMU UAPI is newly introduced to support communications between guest
virtual IOMMU and host IOMMU. There has been lots of discussions on how
it should work with VFIO UAPI and userspace in general.
This document is intended to clarify the UAPI design and usage. The
mechanics of how future
As IOMMU UAPI gets extended, user data size may increase. To support
backward compatibiliy, this patch introduces a size field to each UAPI
data structures. It is *always* the responsibility for the user to fill in
the correct size. Padding fields are adjusted to ensure 8 byte alignment.
Specific
IOMMU UAPI data size is filled by the user space which must be validated
by the kernel. To ensure backward compatibility, user data can only be
extended by either re-purpose padding bytes or extend the variable sized
union at the end. No size change is allowed before the union. Therefore,
the
Hi Jacob,
> -Original Message-
> From: iommu [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of
> Jacob Pan
> Sent: 22 August 2020 05:35
> To: iommu@lists.linux-foundation.org; LKML ;
> Jean-Philippe Brucker ; Lu Baolu
> ; Joerg Roedel ; David
> Woodhouse
> Cc: Tian, Kevin ;
Hi Joerg,
On Thu, 24 Sep 2020 10:40:16 +0200, Joerg Roedel wrote:
> > On Fri, 18 Sep 2020 11:44:50 +0200, Joerg Roedel
> > wrote:
> > > On Fri, Sep 11, 2020 at 02:57:52PM -0700, Jacob Pan wrote:
> > > > There can be multiple vendor-specific PASID data formats used in
> > > > UAPI
Hi Kai
+ Alex, since he had some of the early quirks authored.
On Thu, Sep 24, 2020 at 12:31:53AM +0800, Kai-Heng Feng wrote:
> [+Cc Christoph]
>
> > On Sep 24, 2020, at 00:03, Bjorn Helgaas wrote:
> >
> > [+cc IOMMU and NVMe folks]
> >
> > Sorry, I forgot to forward this to linux-pci when
On Thu, Sep 24, 2020 at 10:58:35AM -0400, Ross Philipson wrote:
> The Secure Launch (SL) stub provides the entry point for Intel TXT (and
> later AMD SKINIT) to vector to during the late launch. The symbol
> sl_stub_entry is that entry point and its offset into the kernel is
> conveyed to the
Hi Joerg,
On Mon, Sep 07, 2020 at 08:54:44PM -0700, Prakhya, Sai Praneeth wrote:
> Presently, the default domain of an iommu group is allocated during boot time
> and it cannot be changed later. So, the device would typically be either in
> identity (pass_through) mode or the device would be in
24.09.2020 17:01, Thierry Reding пишет:
> On Thu, Sep 24, 2020 at 04:23:59PM +0300, Dmitry Osipenko wrote:
>> 04.09.2020 15:59, Thierry Reding пишет:
>>> From: Thierry Reding
>>>
>>> Reserved memory regions can be marked as "active" if hardware is
>>> expected to access the regions during boot
On Mon 21 Sep 16:08 CDT 2020, Will Deacon wrote:
> On Sat, Sep 12, 2020 at 10:25:59PM -0500, Bjorn Andersson wrote:
> > On Fri 11 Sep 12:13 CDT 2020, Robin Murphy wrote:
> > > On 2020-09-04 16:55, Bjorn Andersson wrote:
> > > > Add a new operation to allow platform implementations to inherit any
On Fri, Aug 21, 2020 at 03:15:39PM +0200, Jean-Philippe Brucker wrote:
> Platforms without device-tree nor ACPI can provide a topology
> description embedded into the virtio config space. Parse it.
>
> Use PCI FIXUP to probe the config space early, because we need to
> discover the topology
The routine slaunch_setup is called out of the x86 specific setup_arch
routine during early kernel boot. After determining what platform is
present, various operations specific to that platform occur. This
includes finalizing setting for the platform late launch and verifying
that memory
From: "Daniel P. Smith"
The Secure Launch capability that is part of the compressed kernel
requires the ability to send measurements it takes to the TPM. This
commit introduces the necessary code to communicate with the hardware
interface of TPM devices.
Signed-off-by: Daniel P. Smith
The Trenchboot project focus on boot security has led to the enabling of
the Linux kernel to be directly invocable by the x86 Dynamic Launch
instruction(s) for establishing a Dynamic Root of Trust for Measurement
(DRTM). The dynamic launch will be initiated by a boot loader with
associated support
On Intel, the APs are left in a well documented state after TXT performs
the late launch. Specifically they cannot have #INIT asserted on them so
a standard startup via INIT/SIPI/SIPI cannot be performed. Instead the
early SL stub code parked the APs in a pause/jmp loop waiting for an NMI.
The
From: "Daniel P. Smith"
The late init functionality registers securityfs nodes to allow access
to TXT register fields on Intel along with the fetching of and writing
events to the late launch TPM log.
Signed-off-by: Daniel P. Smith
Signed-off-by: Ross Philipson
Signed-off-by: garnetgrimm
---
The Secure Launch (SL) stub provides the entry point for Intel TXT (and
later AMD SKINIT) to vector to during the late launch. The symbol
sl_stub_entry is that entry point and its offset into the kernel is
conveyed to the launching code using the MLE (Measured Launch
Environment) header in the
The SHA algorithms are necessary to measure configuration information into
the TPM as early as possible before using the values. This implementation
uses the established approach of #including the SHA libraries directly in
the code since the compressed kernel is not uncompressed at this point.
From: "Daniel P. Smith"
This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
above the TPM hardware interface.
Signed-off-by: Daniel P. Smith
Signed-off-by: Ross Philipson
---
arch/x86/boot/compressed/Makefile | 3 +-
arch/x86/boot/compressed/tpm/tpm1.h
Introduce the main Secure Launch header file used in the early SL stub
and the early setup code.
Signed-off-by: Ross Philipson
---
include/linux/slaunch.h | 544
1 file changed, 544 insertions(+)
create mode 100644 include/linux/slaunch.h
diff
Initial bits to bring in Secure Launch functionality. Add Kconfig
options for compiling in/out the Secure Launch code.
Signed-off-by: Ross Philipson
---
arch/x86/Kconfig | 36
1 file changed, 36 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
If the MLE kernel is being powered off, rebooted or halted,
then SEXIT must be called. Note that the SEXIT GETSEC leaf
can only be called after a machine_shutdown() has been done on
these paths. The machine_shutdown() is not called on a few paths
like when poweroff action does not have a poweroff
From: "Daniel P. Smith"
This commit exposes a minimal general interface for the compressed
kernel to request the required TPM operations to send measurements to
a TPM.
Signed-off-by: Daniel P. Smith
Signed-off-by: Ross Philipson
---
arch/x86/boot/compressed/Makefile | 2 +-
Prior to running the next kernel via kexec, the Secure Launch code
closes down private SMX resources and does an SEXIT. This allows the
next kernel to start normally without any issues starting the APs etc.
Signed-off-by: Ross Philipson
---
arch/x86/kernel/slaunch.c | 70
The Secure Launch MLE environment uses PCRs that are only accessible from
the DRTM locality 2. By default the TPM drivers always initialize the
locality to 0. When a Secure Launch is in progress, initialize the
locality to 2.
Signed-off-by: Ross Philipson
---
drivers/char/tpm/tpm-chip.c | 13
On Thu, Sep 24, 2020 at 12:41:29PM +0200, Marek Szyprowski wrote:
> Hi Thierry,
>
> On 24.09.2020 12:16, Thierry Reding wrote:
> > On Thu, Sep 24, 2020 at 10:46:46AM +0200, Marek Szyprowski wrote:
> >> On 24.09.2020 10:28, Joerg Roedel wrote:
> >>> On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek
Hi Robin and Marek,
On Thu, Sep 24, 2020 at 4:36 PM Robin Murphy wrote:
>
> On 2020-09-24 11:47, Marek Szyprowski wrote:
> > Hi Robin,
> >
> > On 24.09.2020 12:40, Robin Murphy wrote:
> >> On 2020-09-24 11:16, Thierry Reding wrote:
> >>> On Thu, Sep 24, 2020 at 10:46:46AM +0200, Marek
From: David Woodhouse
Instead of bailing out completely, such a unit can still be used for
interrupt remapping.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel/dmar.c | 46 +-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git
On Thu, Sep 24, 2020 at 04:23:59PM +0300, Dmitry Osipenko wrote:
> 04.09.2020 15:59, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > Reserved memory regions can be marked as "active" if hardware is
> > expected to access the regions during boot and before the operating
> > system can take
Hi Eric,
On 2020/3/21 0:19, Eric Auger wrote:
The VFIO API was enhanced to support nested stage control: a bunch of
new iotcls, one DMA FAULT region and an associated specific IRQ.
Let's document the process to follow to set up nested mode.
Signed-off-by: Eric Auger
[...]
+The userspace
04.09.2020 15:59, Thierry Reding пишет:
> From: Thierry Reding
>
> Reserved memory regions can be marked as "active" if hardware is
> expected to access the regions during boot and before the operating
> system can take control. One example where this is useful is for the
> operating system to
On Thu, Sep 24, 2020 at 08:41:21AM -0400, Michael S. Tsirkin wrote:
> But this has nothing to do with Linux. There is also no guarantee that
> the two committees will decide to use exactly the same format. Once one
> of them sets the format in stone, we can add support for that format to
> linux.
On Thu, Sep 24, 2020 at 12:02:55PM +0200, Joerg Roedel wrote:
> On Thu, Sep 24, 2020 at 05:38:13AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote:
> > > On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote:
> > > > OK so this looks
On 2020-09-23 11:14, Suravee Suthikulpanit wrote:
Add initial hook up code to implement generic IO page table framework.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/Kconfig | 1 +
drivers/iommu/amd/Makefile | 2 +-
drivers/iommu/amd/amd_iommu_types.h |
On Thu, Sep 24, 2020 at 12:29:53PM +0200, Jean-Philippe Brucker wrote:
> It's not possible to use exactly the same code for parsing.
The access methods can be separate and don't affect the parsing logic.
> The access methods are different (need to deal with port-IO for
> built-in description on
On Tue, Sep 15, 2020 at 02:36:48PM +0200, Thierry Reding wrote:
> On Mon, Sep 14, 2020 at 04:08:29PM -0600, Rob Herring wrote:
> > On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Reserved memory regions can be marked as "active" if hardware
> -Original Message-
> From: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org]
> Sent: 24 September 2020 11:14
> To: Shameerali Kolothum Thodi
> Cc: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org;
> linux...@kvack.org; fenghua...@intel.com;
On 2020-09-24 11:47, Marek Szyprowski wrote:
Hi Robin,
On 24.09.2020 12:40, Robin Murphy wrote:
On 2020-09-24 11:16, Thierry Reding wrote:
On Thu, Sep 24, 2020 at 10:46:46AM +0200, Marek Szyprowski wrote:
On 24.09.2020 10:28, Joerg Roedel wrote:
On Wed, Sep 23, 2020 at 08:48:26AM +0200,
On Wed, Sep 23, 2020 at 12:13:44PM +, Suravee Suthikulpanit wrote:
> Suravee Suthikulpanit (3):
> iommu: amd: Use 4K page for completion wait write-back semaphore
> iommu: amd: Add support for RMP_PAGE_FAULT and RMP_HW_ERR
> iommu: amd: Re-purpose Exclusion range registers to support SNP
On 9/24/20 5:34 PM, Joerg Roedel wrote:
Hi Suravee,
On Wed, Sep 23, 2020 at 10:14:29AM +, Suravee Suthikulpanit wrote:
The framework allows callable implementation of IO page table.
This allows AMD IOMMU driver to switch between different types
of AMD IOMMU page tables (e.g. v1 vs. v2).
Hi Robin,
On 24.09.2020 12:40, Robin Murphy wrote:
> On 2020-09-24 11:16, Thierry Reding wrote:
>> On Thu, Sep 24, 2020 at 10:46:46AM +0200, Marek Szyprowski wrote:
>>> On 24.09.2020 10:28, Joerg Roedel wrote:
On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek Szyprowski wrote:
> It allows
Hi Thierry,
On 24.09.2020 12:16, Thierry Reding wrote:
> On Thu, Sep 24, 2020 at 10:46:46AM +0200, Marek Szyprowski wrote:
>> On 24.09.2020 10:28, Joerg Roedel wrote:
>>> On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek Szyprowski wrote:
It allows to remap given buffer at the specific IOVA
On 2020-09-24 11:16, Thierry Reding wrote:
On Thu, Sep 24, 2020 at 10:46:46AM +0200, Marek Szyprowski wrote:
Hi Joerg,
On 24.09.2020 10:28, Joerg Roedel wrote:
On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek Szyprowski wrote:
It allows to remap given buffer at the specific IOVA address,
Hi Suravee,
On Wed, Sep 23, 2020 at 10:14:29AM +, Suravee Suthikulpanit wrote:
> The framework allows callable implementation of IO page table.
> This allows AMD IOMMU driver to switch between different types
> of AMD IOMMU page tables (e.g. v1 vs. v2).
Is there a reason you created your own
On Fri, Sep 11, 2020 at 12:16:40AM -0700, Nicolin Chen wrote:
> These are a series of small fixes for tegra-smmu driver.
> They might not be critial bugs as current mainline does
> not enable a lot of clients, but be nicer to have since
> we are going to enable the DMA domain for other clients
>
On Thu, Sep 24, 2020 at 12:02:55PM +0200, Joerg Roedel wrote:
> On Thu, Sep 24, 2020 at 05:38:13AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote:
> > > On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote:
> > > > OK so this looks
On Fri, Sep 11, 2020 at 12:16:43AM -0700, Nicolin Chen wrote:
> There can be clients using the same swgroup in DT, for example i2c0
> and i2c1. The current driver will add them to separate IOMMU groups,
> though it has implemented device_group() callback which is to group
> devices using different
On Thu, Sep 24, 2020 at 12:02:55PM +0200, Joerg Roedel wrote:
> On Thu, Sep 24, 2020 at 05:38:13AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote:
> > > On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote:
> > > > OK so this looks
On Fri, Sep 11, 2020 at 12:16:42AM -0700, Nicolin Chen wrote:
> IOVA might not be always 4KB aligned. So tegra_smmu_iova_to_phys
> function needs to add on the lower 12-bit offset from input iova.
>
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/tegra-smmu.c | 2 +-
> 1 file changed, 1
On Fri, Sep 11, 2020 at 12:16:41AM -0700, Nicolin Chen wrote:
> PAGE_SHIFT and PAGE_MASK are defined corresponding to the page size
> for CPU virtual addresses, which means PAGE_SHIFT could be a number
> other than 12, but tegra-smmu maintains fixed 4KB IOVA pages and has
> fixed [21:12] bit range
On Thu, Sep 24, 2020 at 10:46:46AM +0200, Marek Szyprowski wrote:
> Hi Joerg,
>
> On 24.09.2020 10:28, Joerg Roedel wrote:
> > On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek Szyprowski wrote:
> >> It allows to remap given buffer at the specific IOVA address, although
> >> it doesn't guarantee
Hi Shameer,
On Mon, Sep 21, 2020 at 08:59:39AM +, Shameerali Kolothum Thodi wrote:
> > +bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
> > +{
> > + unsigned long reg, fld;
> > + unsigned long oas;
> > + unsigned long asid_bits;
> > + u32 feat_mask = ARM_SMMU_FEAT_BTM |
> >
On Thu, Sep 24, 2020 at 05:38:13AM -0400, Michael S. Tsirkin wrote:
> On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote:
> > On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote:
> > > OK so this looks good. Can you pls repost with the minor tweak
> > > suggested and all
On Tue, Sep 22, 2020 at 02:10:37PM +0800, Lu Baolu wrote:
> Hi Jorge and Alex,
>
> A description of this patch series could be found here.
>
> https://lore.kernel.org/linux-iommu/20200901033422.22249-1-baolu...@linux.intel.com/
Hmm, I am wondering if we can avoid all this hassle and special
On Thu, Sep 24, 2020 at 10:36:47AM +0100, Robin Murphy wrote:
> Yes, the issue was introduced by one of the changes in "dma-mapping:
> introduce DMA range map, supplanting dma_pfn_offset", so it only existed in
> the dma-mapping/for-next branch anyway.
Okay, alright then.
Hi,
Adding Al in the loop
On 9/24/20 11:38 AM, Michael S. Tsirkin wrote:
> On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote:
>> On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote:
>>> OK so this looks good. Can you pls repost with the minor tweak
>>> suggested and all
On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote:
> On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote:
> > OK so this looks good. Can you pls repost with the minor tweak
> > suggested and all acks included, and I will queue this?
>
> My NACK still stands, as long as a
On 2020-09-24 10:25, Joerg Roedel wrote:
Hi Robin,
On Thu, Sep 24, 2020 at 10:08:46AM +0100, Robin Murphy wrote:
This should be fixed by
https://lore.kernel.org/linux-iommu/daedc9364a19dc07487e4d07b8768b1e5934abd4.1600700881.git.robin.mur...@arm.com/T/#u
(already in linux-next).
Thanks! The
Hi Robin,
On Thu, Sep 24, 2020 at 10:08:46AM +0100, Robin Murphy wrote:
> This should be fixed by
> https://lore.kernel.org/linux-iommu/daedc9364a19dc07487e4d07b8768b1e5934abd4.1600700881.git.robin.mur...@arm.com/T/#u
> (already in linux-next).
Thanks! The question remains why this goes through
Hi Jerry,
On Mon, Sep 21, 2020 at 11:56:42AM -0700, Jerry Snitselaar wrote:
> We are seeing a kdump kernel boot failure in test on an HP DL325 Gen10
> and it was tracked down to 387caf0b759a ("iommu/amd: Treat per-device
> exclusion ranges as r/w unity-mapped regions"). Reproduced on 5.9-rc5
>
On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote:
> OK so this looks good. Can you pls repost with the minor tweak
> suggested and all acks included, and I will queue this?
My NACK still stands, as long as a few questions are open:
1) The format used here will be the
Hi Joerg,
On 2020-09-24 10:03, Joerg Roedel wrote:
Adding Will and Robin.
This should be fixed by
https://lore.kernel.org/linux-iommu/daedc9364a19dc07487e4d07b8768b1e5934abd4.1600700881.git.robin.mur...@arm.com/T/#u
(already in linux-next).
Thanks,
Robin.
On Mon, Sep 21, 2020 at
On Wed, Sep 23, 2020 at 10:26:55AM +0800, Baoquan He wrote:
> A regression failure of kdump kernel boot was reported on a HPE system.
> Bisect points at commit 387caf0b759ac43 ("iommu/amd: Treat per-device
> exclusion ranges as r/w unity-mapped regions") as criminal. Reverting it
> fix the
Adding Will and Robin.
On Mon, Sep 21, 2020 at 06:50:40PM +0530, Naresh Kamboju wrote:
> arm64 Freescale Layerscape 2088A RDB Board boot failed with linux-next
> 5.9.0-rc5-next-20200921 kernel tag version. The kernel warning and then
> kernel panic happened.
>
> Reported-by: Naresh Kamboju
>
On Fri, Sep 04, 2020 at 06:24:12PM +0200, Auger Eric wrote:
> Hi,
>
> On 8/21/20 3:15 PM, Jean-Philippe Brucker wrote:
> > Add a topology description to the virtio-iommu driver and enable x86
> > platforms.
> >
> > Since [v2] we have made some progress on adding ACPI support for
> >
On Tue, Sep 22, 2020 at 02:08:42PM +0800, Lu Baolu wrote:
> Below patch is ready for v5.10. It includes:
>
> - Use device numa domain if RHSA is missing
>
> Can you please consider them for v5.10?
>
> Best regards,
> Lu Baolu
>
> Lu Baolu (1):
> iommu/vt-d: Use device numa domain if RHSA is
Hi Eric,
On 2020/3/21 0:19, Eric Auger wrote:
Register an IOMMU fault handler which records faults in
the DMA FAULT region ring buffer. In a subsequent patch, we
will add the signaling of a specific eventfd to allow the
userspace to be notified whenever a new fault as shown up.
Signed-off-by:
On Fri, Sep 18, 2020 at 05:27:59PM +0200, Marek Szyprowski wrote:
> Hi
>
> On 18.09.2020 03:13, Yu Kuai wrote:
> > if of_find_device_by_node() succeed, exynos_iommu_of_xlate() doesn't have
> > a corresponding put_device(). Thus add put_device() to fix the exception
> > handling for this function
Hi Joerg,
On 24.09.2020 10:28, Joerg Roedel wrote:
> On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek Szyprowski wrote:
>> It allows to remap given buffer at the specific IOVA address, although
>> it doesn't guarantee that those specific addresses won't be later used
>> by the IOVA allocator.
Hi Jacob,
On Fri, Sep 18, 2020 at 10:11:08AM -0700, Jacob Pan wrote:
> On Fri, 18 Sep 2020 11:44:50 +0200, Joerg Roedel wrote:
>
> > On Fri, Sep 11, 2020 at 02:57:52PM -0700, Jacob Pan wrote:
> > > There can be multiple vendor-specific PASID data formats used in UAPI
> > > structures. This
On Fri, Sep 04, 2020 at 06:05:35PM +0200, Auger Eric wrote:
> > +static inline int viommu_pci_find_capability(struct pci_dev *dev, u8
> > cfg_type,
> > +struct viommu_cap_config *cap)
> not sure the inline is useful here
No, I'll drop it
Thanks,
Jean
On Fri, Sep 04, 2020 at 06:22:12PM +0200, Auger Eric wrote:
> > +/**
> > + * virt_dma_configure - Configure DMA of virtualized devices
> > + * @dev: the endpoint
> > + *
> > + * Setup the DMA and IOMMU ops of a virtual device, for platforms without
> > DT or
> > + * ACPI.
> > + *
> > + * Return:
On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek Szyprowski wrote:
> It allows to remap given buffer at the specific IOVA address, although
> it doesn't guarantee that those specific addresses won't be later used
> by the IOVA allocator. Probably it would make sense to add an API for
> generic
Hi Eric,
On 2020/3/21 0:19, Eric Auger wrote:
Add a new specific DMA_FAULT region aiming to exposed nested mode
translation faults.
The region has a ring buffer that contains the actual fault
records plus a header allowing to handle it (tail/head indices,
max capacity, entry size). At the
89 matches
Mail list logo
