> From: Jason Gunthorpe
> Sent: Friday, December 10, 2021 8:40 PM
>
>
> > Then Qemu needs to find out the GSI number for the vIRTE handle.
> > Again Qemu doesn't have such information since it doesn't know
> > which MSI[-X] entry points to this handle due to no trap.
>
> No this is already goin
> From: Thomas Gleixner
> Sent: Saturday, December 11, 2021 3:00 AM
>
> Jason,
>
> On Fri, Dec 10 2021 at 08:39, Jason Gunthorpe wrote:
>
> > On Fri, Dec 10, 2021 at 07:29:01AM +, Tian, Kevin wrote:
> >> > 5) It's not possible for the kernel to reliably detect whether it is
> >> > ru
fig: arm64-randconfig-r014-20211210
(https://download.01.org/0day-ci/archive/20211211/202112110744.cwu0wc1o-...@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
097a1cb1d5ebb3a0ec4bcaed8ba3ff6a8e33c00a)
reproduce (this is a W=1 build):
w
onfig: arm-randconfig-r013-20211210
(https://download.01.org/0day-ci/archive/20211211/202112110753.vybslmnq-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
From: Thomas Gleixner
Just use the core function msi_get_virq().
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Peter Ujfalusi
Cc: Vinod Koul
Cc: dmaeng...@vger.kernel.org
---
drivers/dma/ti/k3-udma-private.c |6 ++
drivers/dma
From: Thomas Gleixner
There is no reason to walk the MSI descriptors to retrieve the interrupt
number for a device. Use msi_get_virq() instead.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Acked-by: Sinan Kaya
Cc: dmaeng...@vger.kernel.org
---
From: Thomas Gleixner
Storing a pointer to the MSI descriptor just to track the Linux interrupt
number is daft. Just store the interrupt number and be done with it.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Stuart Yoder
Cc: Laurentiu Tudo
From: Thomas Gleixner
No point in retrieving the MSI descriptors. Just query the Linux interrupt
number.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Jassi Brar
---
drivers/mailbox/bcm-flexrm-mailbox.c |7 ++-
1 file changed, 2 ins
From: Thomas Gleixner
Let the core code fiddle with the MSI descriptor retrieval.
Signed-off-by: Thomas Gleixner
Tested-by: Robin Murphy
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Will Deacon
Cc: Joerg Roedel
Cc: linux-arm-ker...@lists.infradead.org
Cc: iommu@lists.li
From: Thomas Gleixner
Let the core code fiddle with the MSI descriptor retrieval.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Mark Rutland
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/perf/arm_smmuv3_pmu.c |5 +
From: Thomas Gleixner
Storing a pointer to the MSI descriptor just to keep track of the Linux
interrupt number is daft. Use msi_get_virq() instead.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Vinod Koul
Cc: dmaeng...@vger.kernel.org
---
dr
From: Thomas Gleixner
Replace open coded MSI descriptor chasing and use the proper accessor
functions instead.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi/msi.c | 26 ++
1 file changed, 10 insertion
From: Thomas Gleixner
Use msi_get_vector() and handle the return value to be compatible.
No functional change intended.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
---
V2: Handle the INTx case directly instead of trying to be overly smart - Marc
---
drivers/pci/msi/msi.c |
From: Thomas Gleixner
This allows drivers to retrieve the Linux interrupt number instead of
fiddling with MSI descriptors.
msi_get_virq() returns the Linux interrupt number or 0 in case that there
is no entry for the given MSI index.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartm
From: Thomas Gleixner
Set the domain info flag and remove the check.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: "Cédric Le Goater"
Cc: linuxppc-...@lists.ozlabs.org
---
V2: Remove it completely - Cedric
---
arch/power
From: Thomas Gleixner
Provide a domain info flag which makes the core code check for a contiguous
MSI-X index on allocation. That's simpler than checking it at some other
domain callback in architecture code.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gun
From: Thomas Gleixner
The usage of msi_desc::pci::entry_nr is confusing at best. It's the index
into the MSI[X] descriptor table.
Use msi_desc::msi_index which is shared between all MSI incarnations
instead of having a PCI specific storage for no value.
Signed-off-by: Thomas Gleixner
Reviewed-
From: Thomas Gleixner
Use the common msi_index member and get rid of the pointless wrapper struct.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Stuart Yoder
Cc: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-allocator.c |2 +-
drivers/b
From: Thomas Gleixner
Use the common msi_index member and get rid of the pointless wrapper struct.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Nishanth Menon
Cc: Tero Kristo
Cc: Santosh Shilimkar
Cc: Thomas Gleixner
Cc: linux-arm-ker...@
From: Thomas Gleixner
Storing the platform private data in a MSI descriptor is sloppy at
best. The data belongs to the device and not to the descriptor.
Add a pointer to struct msi_device_data and store the pointer there.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-
From: Thomas Gleixner
Use the common msi_index member and get rid of the pointless wrapper struct.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
drivers/base/platform-msi.c | 10 +-
drivers/dma/qcom/hidma.c
From: Thomas Gleixner
All non PCI/MSI usage variants have data structures in struct msi_desc with
only one member: xxx_index. PCI/MSI has a entry_nr member.
Add a common msi_index member to struct msi_desc so all implementations can
share it which allows further consolidation.
Signed-off-by: Th
From: Thomas Gleixner
It's hard to distinguish what platform_msi_domain_alloc() and
platform_msi_domain_alloc_irqs() are about. Make the distinction more
explicit and add comments which explain the use cases properly.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by:
From: Thomas Gleixner
No more users. Refactor the core code accordingly and move the global
interface under CONFIG_PCI_MSI_ARCH_FALLBACKS.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
include/linux/msi.h | 29 +++-
From: Thomas Gleixner
Set the domain info flag and remove the local sysfs code.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
drivers/base/platform-msi.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
--- a/drivers/base/
From: Thomas Gleixner
Set the domain info flag which makes the core code handle sysfs groups and
put an explicit invocation into the legacy code.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
---
drivers/pci/msi/irqdomain
From: Thomas Gleixner
Add new allocation functions which can be activated by domain info
flags. They store the groups pointer in struct msi_device_data.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
include/linux/msi.h |4
kernel/irq
From: Thomas Gleixner
Allocate the MSI device data on first invocation of the allocation function.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Nishanth Menon
Cc: Tero Kristo
Cc: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org
-
From: Thomas Gleixner
Allocate the MSI device data on first invocation of the allocation function.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Stuart Yoder
Cc: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-msi.c | 14 --
1 f
From: Thomas Gleixner
Allocate MSI device data on first use, i.e. when a PCI driver invokes one
of the PCI/MSI enablement functions.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
---
drivers/pci/msi/msi.c | 20 +
From: Thomas Gleixner
Allocate the MSI device data on first invocation of the allocation function
for platform MSI private data.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
drivers/base/platform-msi.c |8 +++-
1 file changed, 7 inse
From: Thomas Gleixner
Create struct msi_device_data and add a pointer of that type to struct
dev_msi_info, which is part of struct device. Provide an allocator function
which can be invoked from the MSI interrupt allocation code pathes.
Add a properties field to the data structure as a first mem
From: Thomas Gleixner
The only unconditional part of MSI data in struct device is the irqdomain
pointer. Everything else can be allocated on demand. Create a data
structure and move the irqdomain pointer into it. The other MSI specific
parts are going to be removed from struct device in later ste
From: Thomas Gleixner
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
Cc: Michael Ellerman
Cc: linuxppc-...@lists.ozlabs.org
---
V3: Use pci_dev->msix_enabled - Jason
---
arch/powerpc/platforms/pseries/msi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Thomas Gleixner
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
Cc: Arnd Bergmann
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: linuxppc-...@lists.ozlabs.org
---
V3: Use pci_dev property - Jason
V2: Invoke the function with the correct number of arguments
This is the second part of [PCI]MSI refactoring which aims to provide the
ability of expanding MSI-X vectors after enabling MSI-X.
This is based on the first part of this work which can be found here:
https://lore.kernel.org/r/20211206210147.872865...@linutronix.de
and has been applied to:
From: Thomas Gleixner
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
---
V3: Use pci_dev->msix_enabled - Jason
---
arch/x86/kernel/apic/msi.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.
From: Thomas Gleixner
to determine whether this is MSI or MSIX instead of consulting MSI
descriptors.
Signed-off-by: Thomas Gleixner
---
V2: Use PCI device property - Jason
---
kernel/irq/msi.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
--- a/kernel/irq/msi.c
+
From: Thomas Gleixner
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: xen-de...@lists.xenproject.org
---
V3: Use pci_dev->msix_enabled.
---
arch/x86/pci/xen.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/arch/x86/pci/x
There are quite some places which retrieve the first MSI descriptor to
evaluate whether the setup is for MSI or MSI-X. That's required because
pci_dev::msi[x]_enabled is only set when the setup completed successfully.
There is no real reason why msi[x]_enabled can't be set at the beginning of
the
Since commit baf94e6ebff9 ("iommu/mediatek: Add device link for smi-common
and m4u"), the driver assumes that at least one phandle associated with
"mediatek,larbs" exists. If that is not the case, for example if reason
"mediatek,larbs" is provided as boolean property, the code will use an
uninitial
On 10 Dec 2021, at 13:36, David Hildenbrand wrote:
> On 10.12.21 00:04, Zi Yan wrote:
>> From: Zi Yan
>>
>> Hi all,
>
> Hi,
>
> thanks for working on that!
>
>>
>> This patchset tries to remove the MAX_ORDER - 1 alignment requirement for CMA
>> and alloc_contig_range(). It prepares for my upcomin
On 10/12/2021 18:13, Robin Murphy wrote:
possible for the timeout to expire just*before* the del_timer() call
super nit: "just*before* the" - needs a whitespace before "before" :)
Weird... the original patch file here and the copy received by lore via
linux-iommu look fine, gremlins in you
Jason,
On Fri, Dec 10 2021 at 08:39, Jason Gunthorpe wrote:
> On Fri, Dec 10, 2021 at 07:29:01AM +, Tian, Kevin wrote:
>> > 5) It's not possible for the kernel to reliably detect whether it is
>> > running on bare metal or not. Yes we talked about heuristics, but
>> > that's somet
On Fri, Dec 10, 2021 at 10:18:20AM -0800, Jacob Pan wrote:
> > If one device has 10 PASID's pointing to this domain you must flush
> > them all if that is what the HW requires.
> >
> Yes. My point is that other than PASID 0 is a given, we must track the 10
> PASIDs to avoid wasted flush. It also
On 10.12.21 00:04, Zi Yan wrote:
> From: Zi Yan
>
> Hi all,
Hi,
thanks for working on that!
>
> This patchset tries to remove the MAX_ORDER - 1 alignment requirement for CMA
> and alloc_contig_range(). It prepares for my upcoming changes to make
> MAX_ORDER
> adjustable at boot time[1].
>
>
Hi Jason,
On Fri, 10 Dec 2021 13:48:48 -0400, Jason Gunthorpe wrote:
> On Fri, Dec 10, 2021 at 09:50:25AM -0800, Jacob Pan wrote:
>
> > > Tying pasid to an iommu_domain is not a good idea. An iommu_domain
> > > represents an I/O address translation table. It could be attached to a
> > > device
On 2021-12-10 18:04, John Garry via iommu wrote:
On 10/12/2021 17:54, Robin Murphy wrote:
From: Xiongfeng Wang
It turns out to be possible for hotplugging out a device to reach the
stage of tearing down the device's group and default domain before the
domain's flush queue has drained naturally.
On 10/12/2021 17:54, Robin Murphy wrote:
From: Xiongfeng Wang
It turns out to be possible for hotplugging out a device to reach the
stage of tearing down the device's group and default domain before the
domain's flush queue has drained naturally. At this point, it is then
possible for the timeou
Hi Jason,
On Fri, 10 Dec 2021 08:31:09 -0400, Jason Gunthorpe wrote:
> On Fri, Dec 10, 2021 at 09:06:24AM +, Jean-Philippe Brucker wrote:
> > On Thu, Dec 09, 2021 at 10:14:04AM -0800, Jacob Pan wrote:
> > > > This looks like we're just one step away from device drivers needing
> > > > mult
On Fri, Dec 10, 2021 at 8:08 AM Zi Yan wrote:
>
> On 10 Dec 2021, at 2:53, Eric Ren wrote:
>
> > Hi,
> >
> > On 2021/12/10 07:04, Zi Yan wrote:
> >> From: Zi Yan
> >>
> >> alloc_migration_target() is used by alloc_contig_range() and non-LRU
> >> movable compound pages can be migrated. Current cod
Complete the move into iommu-dma by refactoring the flush queues
themselves to belong to the DMA cookie rather than the IOVA domain.
The refactoring may as well extend to some minor cosmetic aspects
too, to help us stay one step ahead of the style police.
Signed-off-by: Robin Murphy
---
v2: Reb
Flush queues are specific to DMA ops, which are now handled exclusively
by iommu-dma. As such, now that the historical artefacts from being
shared directly with drivers have been cleaned up, move the flush queue
code into iommu-dma itself to get it out of the way of other IOVA users.
This is pure
Squash and simplify some of the freeing code, and move the init
and free routines down into the rest of the flush queue code to
obviate the forward declarations.
Signed-off-by: Robin Murphy
---
v2: Rebase with del_timer_sync() change
drivers/iommu/iova.c | 131 +++--
From: "Matthew Wilcox (Oracle)"
page->freelist is for the use of slab. We already have the ability
to free a list of pages in the core mm, but it requires the use of a
list_head and for the pages to be chained together through page->lru.
Switch the Intel IOMMU and IOVA code over to using free_pa
From: "Matthew Wilcox (Oracle)"
page->freelist is for the use of slab. We already have the ability
to free a list of pages in the core mm, but it requires the use of a
list_head and for the pages to be chained together through page->lru.
Switch the AMD IOMMU code over to using free_pages_list().
For reasons unclear, pagetable freeing is an effectively recursive
method implemented via an elaborate system of templated functions that
turns out to account for 25% of the object file size. Implementing it
using regular straightforward recursion makes the code simpler, and
seems like a good thing
Once again, with iommu-dma now being the only flush queue user, we no
longer need the extra level of indirection through flush_cb. Squash that
and let the flush queue code call the domain method directly.
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/dma-iommu.c | 13 +---
All flush queues are driven by iommu-dma now, so there is no need to
abstract entry_dtor or its data any more. Squash the now-canonical
implementation directly into the IOVA code to get it out of the way.
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/dma-iommu.c | 17 ++--
Upon failure, dma_alloc_coherent() returns NULL. If that does happen,
passing some uninitialised stack contents to dma_mapping_error() - which
belongs to a different API in the first place - has precious little
chance of detecting it.
Also include the correct header, because the fragile transitive
Host1x seems to be relying on picking up dma-mapping.h transitively from
iova.h, which has no reason to include it in the first place. Fix the
former issue before we totally break things by fixing the latter one.
CC: Thierry Reding
CC: Mikko Perttunen
CC: dri-de...@lists.freedesktop.org
Signed-o
From: Xiongfeng Wang
It turns out to be possible for hotplugging out a device to reach the
stage of tearing down the device's group and default domain before the
domain's flush queue has drained naturally. At this point, it is then
possible for the timeout to expire just *before* the del_timer()
v1:
https://lore.kernel.org/linux-iommu/cover.1637671820.git.robin.mur...@arm.com/
Hi all,
Just a minor update, pulling in Xiongfeng's fix as a basis for the
subsequent patches moving that code around, and the Tegra DRM patch
previously posted separately. Plus commenting the subtlety in the AMD
On Fri, Dec 10, 2021 at 09:50:25AM -0800, Jacob Pan wrote:
> > Tying pasid to an iommu_domain is not a good idea. An iommu_domain
> > represents an I/O address translation table. It could be attached to a
> > device or a PASID on the device.
>
> I don;t think we can avoid storing PASID at domain
Hi Lu,
On Fri, 10 Dec 2021 14:46:32 +0800, Lu Baolu
wrote:
> On 2021/12/10 7:21, Jacob Pan wrote:
> > On Thu, 9 Dec 2021 10:32:43 +0800, Lu Baolu
> > wrote:
> >
> >> On 12/9/21 3:16 AM, Jacob Pan wrote:
> >>> Hi Jason,
> >>>
> >>> On Wed, 8 Dec 2021 09:22:55 -0400, Jason Gunthorpe
> >>> wro
On 10 Dec 2021, at 2:53, Eric Ren wrote:
> Hi,
>
> On 2021/12/10 07:04, Zi Yan wrote:
>> From: Zi Yan
>>
>> alloc_migration_target() is used by alloc_contig_range() and non-LRU
>> movable compound pages can be migrated. Current code does not allocate the
>> right page size for such pages. Check T
Hi Eric,
Thanks for looking into my patch.
On 10 Dec 2021, at 2:43, Eric Ren wrote:
> Hi,
>
> On 2021/12/10 07:04, Zi Yan wrote:
>> From: Zi Yan
>>
>> This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
>> It prepares for the upcoming removal of the MAX_ORDER-1 alignment
>> r
On 10 Dec 2021, at 2:30, Eric Ren wrote:
> Hi Zi Yan,
>
> On 2021/12/10 07:04, Zi Yan wrote:
>> From: Zi Yan
>>
>> Hi all,
>>
>> This patchset tries to remove the MAX_ORDER - 1 alignment requirement for CMA
>> and alloc_contig_range(). It prepares for my upcoming changes to make
>> MAX_ORDER
>>
On 12/10/2021 9:25 PM, Tianyu Lan wrote:
@@ -319,8 +320,16 @@ static void __init ms_hyperv_init_platform(void)
pr_info("Hyper-V: Isolation Config: Group A 0x%x, Group B
0x%x\n",
ms_hyperv.isolation_config_a,
ms_hyperv.isolation_config_b);
- if (hv_get_isolatio
On 12/10/2021 4:09 AM, Michael Kelley (LINUX) wrote:
@@ -319,8 +320,16 @@ static void __init ms_hyperv_init_platform(void)
pr_info("Hyper-V: Isolation Config: Group A 0x%x, Group B
0x%x\n",
ms_hyperv.isolation_config_a,
ms_hyperv.isolation_config_b);
-
On Fri, Dec 10, 2021 at 07:29:01AM +, Tian, Kevin wrote:
> > 5) It's not possible for the kernel to reliably detect whether it is
> > running on bare metal or not. Yes we talked about heuristics, but
> > that's something I really want to avoid.
>
> How would the hypercall mechanism
On Fri, Dec 10, 2021 at 09:06:24AM +, Jean-Philippe Brucker wrote:
> On Thu, Dec 09, 2021 at 10:14:04AM -0800, Jacob Pan wrote:
> > > This looks like we're just one step away from device drivers needing
> > > multiple PASIDs for kernel DMA so I'm trying to figure out how to evolve
> > > the API
On Fri, Dec 10, 2021 at 07:36:12AM +, Tian, Kevin wrote:
> /*
> * The MSIX mappable capability informs that MSIX data of a BAR can be mmapped
> * which allows direct access to non-MSIX registers which happened to be
> within
> * the same system page.
> *
> * Even though the userspace get
Kevin,
On Fri, Dec 10 2021 at 07:29, Kevin Tian wrote:
>> From: Thomas Gleixner
>> 4) For the guest side we agreed that we need an hypercall because the
>> host can't trap the write to the MSI[-X] entry anymore.
>
> To be accurate I'd like to not call it "can't trap". The host still traps
On Thu, Nov 18, 2021 at 03:50:54PM +, Robin Murphy wrote:
> > > + An SMMUv3 may have several Performance Monitor Counter Group (PMCG).
> > > + They are standalone performance monitoring units that support both
> > > + architected and IMPLEMENTATION DEFINED event counters.
> >
> > Humm, I do
On 12/10/2021 4:38 AM, Michael Kelley (LINUX) wrote:
From: Tianyu Lan Sent: Monday, December 6, 2021 11:56 PM
Hyper-V provides Isolation VM which has memory encrypt support. Add
hyperv_cc_platform_has() and return true for check of GUEST_MEM_ENCRYPT
attribute.
Signed-off-by: Tianyu Lan
---
C
On Sat, Dec 04, 2021 at 11:33:01PM +0100, Rikard Falkeborn wrote:
> The only usage of arm_smmu_mmu_notifier_ops is to assign its address to
> the ops field in the mmu_notifier struct, which is a pointer to const
> struct mmu_notifier_ops. Make it const to allow the compiler to put it
> in read-only
On Thu, Dec 09, 2021 at 10:14:04AM -0800, Jacob Pan wrote:
> > This looks like we're just one step away from device drivers needing
> > multiple PASIDs for kernel DMA so I'm trying to figure out how to evolve
> > the API towards that. It's probably as simple as keeping a kernel IOASID
> > set at fi
On Thu, 2021-12-02 at 01:08 +0200, Maxim Levitsky wrote:
> On Tue, 2021-11-23 at 18:10 +0200, Maxim Levitsky wrote:
> > As I sadly found out, a s3 cycle makes the AMD's iommu stop sending
> > interrupts
> > until the system is rebooted.
> >
> > I only noticed it now because otherwise the IOMMU wo
79 matches
Mail list logo
