Hi David,
On 6/3/21 1:54 PM, David Gibson wrote:
On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
Hi Jason,
On 2021/5/29 7:36, Jason Gunthorpe wrote:
/*
* Bind an user-managed I/O page table with the IOMMU
*
* Because user page table is untrusted, IOASID nesting must be e
> From: David Gibson
> Sent: Thursday, June 3, 2021 1:09 PM
[...]
> > > In this way the SW mode is the same as a HW mode with an infinite
> > > cache.
> > >
> > > The collaposed shadow page table is really just a cache.
> > >
> >
> > OK. One additional thing is that we may need a 'caching_mode"
> >
> From: Jason Gunthorpe
> Sent: Saturday, May 29, 2021 7:37 AM
>
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
>
> > 2.1. /dev/ioasid uAPI
> > +
> >
> > /*
> > * Check whether an uAPI extension is supported.
> > *
> > * This is for FD-level capabilities, su
On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
> Hi Jason,
>
> On 2021/5/29 7:36, Jason Gunthorpe wrote:
> > > /*
> > >* Bind an user-managed I/O page table with the IOMMU
> > >*
> > >* Because user page table is untrusted, IOASID nesting must be enabled
> > >* for this
On Wed, Jun 02, 2021 at 02:19:30PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 04:15:07PM +1000, David Gibson wrote:
>
> > Is there a compelling reason to have all the IOASIDs handled by one
> > FD?
>
> There was an answer on this, if every PASID needs an IOASID then there
> are too m
On Wed, Jun 02, 2021 at 01:16:48PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 04:32:27PM +1000, David Gibson wrote:
> > > I agree with Jean-Philippe - at the very least erasing this
> > > information needs a major rational - but I don't really see why it
> > > must be erased? The HW re
On Wed, Jun 02, 2021 at 01:58:38PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > > /* Bind guest I/O page table */
> > > > bind_data = {
> > > > .ioasid = gva_ioasid;
> > > > .addr = gva_pgtable
On Thu, Jun 03, 2021 at 02:49:56AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, June 3, 2021 12:59 AM
> >
> > On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > > > /* Bind guest I/O page table */
> > > > > bind_data = {
> > > > >
On Wed, Jun 02, 2021 at 01:37:53PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 04:57:52PM +1000, David Gibson wrote:
>
> > I don't think presence or absence of a group fd makes a lot of
> > difference to this design. Having a group fd just means we attach
> > groups to the ioasid inst
On Thu, Jun 03, 2021 at 01:29:58AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, June 3, 2021 12:09 AM
> >
> > On Wed, Jun 02, 2021 at 01:33:22AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Wednesday, June 2, 2021 1:42 AM
> > > >
> > > > On Tue,
On 6/3/21 7:23 AM, Jason Gunthorpe wrote:
On Wed, Jun 02, 2021 at 12:01:57PM +0800, Lu Baolu wrote:
On 6/2/21 1:26 AM, Jason Gunthorpe wrote:
On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
This version only covers 1) and 4). Do you think we need to support 2),
3) and beyond?
Yes
> From: Alex Williamson
> Sent: Thursday, June 3, 2021 12:15 PM
>
> On Thu, 3 Jun 2021 03:22:27 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Thursday, June 3, 2021 10:51 AM
> > >
> > > On Wed, 2 Jun 2021 19:45:36 -0300
> > > Jason Gunthorpe wrote:
> > >
> > > > On We
On Thu, 3 Jun 2021 03:22:27 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, June 3, 2021 10:51 AM
> >
> > On Wed, 2 Jun 2021 19:45:36 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wrote:
> > >
> > > > Right.
On 6/2/21 5:41 PM, Andi Kleen wrote:
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return is_tdx_guest();
+}
+EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
+
This function definition had to be removed from arch/x86/mm/mem_encrypt.c.
Otherwise, if you enable b
> From: Alex Williamson
> Sent: Thursday, June 3, 2021 10:51 AM
>
> On Wed, 2 Jun 2021 19:45:36 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wrote:
> >
> > > Right. I don't follow where you're jumping to relaying DMA_PTE_SNP
> > > from the gues
在 2021/6/3 上午10:56, Andi Kleen 写道:
I agree, but I want to know why indirect descriptor needs to be
disabled. The table can't be wrote by the device since it's not
coherent swiotlb mapping.
I had all kinds of problems with uninitialized entries in the indirect
table. So I gave up on it an
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 1:20 AM
>
[...]
> > I wonder if there's a way to model this using a nested AS rather than
> > requiring special operations. e.g.
> >
> > 'prereg' IOAS
> > |
> > \- 'rid' IOAS
> >|
> >\- 'pasid' IOAS (maybe)
> >
>
I agree, but I want to know why indirect descriptor needs to be
disabled. The table can't be wrote by the device since it's not
coherent swiotlb mapping.
I had all kinds of problems with uninitialized entries in the indirect
table. So I gave up on it and concluded it would be too difficul
在 2021/6/3 上午4:37, Alex Williamson 写道:
On Wed, 2 Jun 2021 16:54:04 -0300
Jason Gunthorpe wrote:
On Wed, Jun 02, 2021 at 01:00:53PM -0600, Alex Williamson wrote:
Right, the device can generate the no-snoop transactions, but it's the
IOMMU that essentially determines whether those transactions
On Wed, 2 Jun 2021 19:45:36 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wrote:
>
> > Right. I don't follow where you're jumping to relaying DMA_PTE_SNP
> > from the guest page table... what page table?
>
> I see my confusion now, the phrasing in
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 12:59 AM
>
> On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > > /* Bind guest I/O page table */
> > > > bind_data = {
> > > > .ioasid = gva_ioasid;
> > > > .addr = gva_pgta
在 2021/6/3 上午10:18, Andi Kleen 写道:
It looks to me all the evils came from the fact that we depends on
the descriptor ring.
So the checks in this patch could is unnecessary if we don't even
read from the descriptor ring which could be manipulated by the device.
This is what my series tries
在 2021/6/3 上午9:48, Andi Kleen 写道:
So we will see huge performance regression without indirect
descriptor. We need to consider to address this.
A regression would be when some existing case would be slower.
That's not the case because the behavior for the existing cases does
not change.
A
在 2021/6/3 上午8:41, Andi Kleen 写道:
Harden the split buffer detachment path by adding boundary checking. Note
that when this fails we may fail to unmap some swiotlb mapping, which could
result in a leak and a DOS. But that's acceptable because an malicious host
can DOS us anyways.
Signed-off-by:
It looks to me all the evils came from the fact that we depends on the
descriptor ring.
So the checks in this patch could is unnecessary if we don't even read
from the descriptor ring which could be manipulated by the device.
This is what my series tries to achieve:
https://www.spinics.ne
在 2021/6/3 上午8:41, Andi Kleen 写道:
In protected guest mode we don't trust the host.
This means we need to make sure the host cannot subvert us through
virtio communication. In general it can corrupt our virtio data
and cause a DOS, but it should not be able to access any data
that is not explici
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 12:17 AM
>
[...]
> > > If there are no hypervisor traps (does this exist?) then there is no
> > > way to involve the hypervisor here and the child IOASID should simply
> > > be a pointer to the guest's data structure that describes binding. I
On 6/2/2021 6:48 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 02, 2021 at 05:41:30PM -0700, Andi Kleen wrote:
swiotlb currently only uses the start address of a DMA to check if something
is in the swiotlb or not. But with virtio and untrusted hosts the host
could give some DMA mapping that cro
Note that it's probably needed by other cases as well:
1) Other encrypted VM technology
2) VDUSE[1]
3) Smart NICs
Right. I don't see any reason why these shouldn't work. You may just
need to add the enable for the lockdown, but you can reuse the basic
infrastructure.
We have already had
So we will see huge performance regression without indirect
descriptor. We need to consider to address this.
A regression would be when some existing case would be slower.
That's not the case because the behavior for the existing cases does not
change.
Anyways when there are performance pr
swiotlb currently only uses the start address of a DMA to check if something
is in the swiotlb or not. But with virtio and untrusted hosts the host
could give some DMA mapping that crosses the swiotlb boundaries,
potentially leaking or corrupting data. Add size checks to all the swiotlb
checks and
Error out with a warning when the free list loops longer
than the maximum size while freeing descriptors. While technically
we don't care about DOS it is still better to abort it early.
We ran into this problem while fuzzing the virtio interactions
where the fuzzed code would get stuck for a long
Harden the split buffer detachment path by adding boundary checking. Note
that when this fails we may fail to unmap some swiotlb mapping, which could
result in a leak and a DOS. But that's acceptable because an malicious host
can DOS us anyways.
Signed-off-by: Andi Kleen
---
drivers/virtio/virti
In virtio the host decides whether the guest uses the DMA
API or not using the strangely named VIRTIO_F_ACCESS_PLATFORM
bit (which really indicates whether the DMA API is used or not)
For hardened virtio on TDX we want to enforce that that swiotlb is
always used, which requires using the DMA API.
When running under TDX the virtio host is untrusted. The bulk
of the kernel memory is encrypted and protected, but the virtio
ring is in special shared memory that is shared with the
untrusted host.
This means virtio needs to be hardened against any attacks from
the host through the ring. Of cours
Now that we have a return value for unmapping DMA mappings that
are outside the forced swiotlb, use that to abort the IO operation.
This prevents the host from subverting a read to access some
data in the guest address space, which it might then get access somehow in
another IO operation. It can s
In protected guest mode we don't trust the host.
This means we need to make sure the host cannot subvert us through
virtio communication. In general it can corrupt our virtio data
and cause a DOS, but it should not be able to access any data
that is not explicitely under IO.
Also boundary checkin
[v1: Initial post]
With confidential computing like TDX the guest doesn't trust the host
anymore. The host is allowed to DOS of course, but it is not allowed
to read or write any guest memory not explicitely shared with it.
This has implication for virtio. Traditionally virtio didn't assume
the o
In some situations when we know swiotlb is forced and we have
to deal with untrusted hosts, it's useful to know if a mapping
was in the swiotlb or not. This allows us to abort any IO
operation that would access memory outside the swiotlb.
Otherwise it might be possible for a malicious host to inje
On Wed, Jun 02, 2021 at 05:41:30PM -0700, Andi Kleen wrote:
> swiotlb currently only uses the start address of a DMA to check if something
> is in the swiotlb or not. But with virtio and untrusted hosts the host
> could give some DMA mapping that crosses the swiotlb boundaries,
> potentially leakin
在 2021/6/3 上午8:41, Andi Kleen 写道:
When running under TDX the virtio host is untrusted. The bulk
of the kernel memory is encrypted and protected, but the virtio
ring is in special shared memory that is shared with the
untrusted host.
This means virtio needs to be hardened against any attacks fro
在 2021/6/3 上午8:41, Andi Kleen 写道:
[v1: Initial post]
With confidential computing like TDX the guest doesn't trust the host
anymore. The host is allowed to DOS of course, but it is not allowed
to read or write any guest memory not explicitely shared with it.
This has implication for virtio. Tra
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 12:09 AM
>
> On Wed, Jun 02, 2021 at 01:33:22AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, June 2, 2021 1:42 AM
> > >
> > > On Tue, Jun 01, 2021 at 08:10:14AM +, Tian, Kevin wrote:
> > > > > From: Jason G
On 6/2/21 3:48 PM, John Garry wrote:
On 02/06/2021 05:37, Lu Baolu wrote:
On 6/1/21 10:29 PM, John Garry wrote:
For streaming DMA mappings involving an IOMMU and whose IOVA len
regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This i
On Wed, Jun 02, 2021 at 01:25:00AM +, Tian, Kevin wrote:
> OK, this implies that if one user inadvertently creates intended parent/
> child via different fd's then the operation will simply fail.
Remember the number space to refer to the ioasid's inside the FD is
local to that instance of the
On Wed, Jun 02, 2021 at 12:01:57PM +0800, Lu Baolu wrote:
> On 6/2/21 1:26 AM, Jason Gunthorpe wrote:
> > On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
> >
> > > This version only covers 1) and 4). Do you think we need to support 2),
> > > 3) and beyond?
> >
> > Yes aboslutely. The AP
On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wrote:
> Right. I don't follow where you're jumping to relaying DMA_PTE_SNP
> from the guest page table... what page table?
I see my confusion now, the phrasing in your earlier remark led me
think this was about allowing the no-snoop pe
>> ... so on a PASID system, your trivial reproducer would theoretically
>> fire the same way and corrupt FPU state just as well.
>
> This is worse and you can't selftest it because the IPI can just hit in
> the middle of _any_ FPU state operation and corrupt state.
That sounds like we should aban
On Wed, 2 Jun 2021 16:54:04 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 01:00:53PM -0600, Alex Williamson wrote:
> >
> > Right, the device can generate the no-snoop transactions, but it's the
> > IOMMU that essentially determines whether those transactions are
> > actually still cache
Hi,
I just ran into the exact same issue while working on the M1 DART IOMMU driver
and it was fixed by this commit. Thanks!
Would be great if this could be picked up.
Tested-by: Sven Peter
Best,
Sven
On Mon, Sep 14, 2020, at 09:23, Srinath Mannam via iommu wrote:
> Fix IOVA reserve failur
Hi Jean-Philippe,
I love your patch! Yet something to improve:
[auto build test ERROR on pm/linux-next]
[also build test ERROR on iommu/next arm64/for-next/core linus/master v5.13-rc4
next-20210602]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Wed, Jun 02, 2021 at 01:00:53PM -0600, Alex Williamson wrote:
> On Wed, 2 Jun 2021 15:09:25 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Jun 02, 2021 at 12:01:11PM -0600, Alex Williamson wrote:
> > > On Wed, 2 Jun 2021 14:35:10 -0300
> > > Jason Gunthorpe wrote:
> > >
> > > > On Wed, Jun 0
On Wed, 2 Jun 2021 15:09:25 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 12:01:11PM -0600, Alex Williamson wrote:
> > On Wed, 2 Jun 2021 14:35:10 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Jun 02, 2021 at 11:11:17AM -0600, Alex Williamson wrote:
> > >
> > > > > > > presen
On Wed, Jun 02, 2021 at 12:01:11PM -0600, Alex Williamson wrote:
> On Wed, 2 Jun 2021 14:35:10 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Jun 02, 2021 at 11:11:17AM -0600, Alex Williamson wrote:
> >
> > > > > > present and be able to test if DMA for that device is cache
> > > > > > coherent.
On Wed, 2 Jun 2021 14:35:10 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 11:11:17AM -0600, Alex Williamson wrote:
>
> > > > > present and be able to test if DMA for that device is cache
> > > > > coherent.
> > >
> > > Why is this such a strong linkage to VFIO and not just a 'hey k
On Wed, Jun 02, 2021 at 11:11:17AM -0600, Alex Williamson wrote:
> > > > present and be able to test if DMA for that device is cache
> > > > coherent.
> >
> > Why is this such a strong linkage to VFIO and not just a 'hey kvm
> > emulate wbinvd' flag from qemu?
>
> IIRC, wbinvd has host implica
On Wed, Jun 02, 2021 at 10:56:48AM +0200, Enrico Weigelt, metux IT consult
wrote:
> If I understand this correctly, /dev/ioasid is a kind of "common supplier"
> to other APIs / devices. Why can't the fd be acquired by the
> consumer APIs (eg. kvm, vfio, etc) ?
/dev/ioasid would be similar to /de
On Wed, Jun 02, 2021 at 04:54:26PM +0800, Jason Wang wrote:
>
> 在 2021/6/2 上午1:31, Jason Gunthorpe 写道:
> > On Tue, Jun 01, 2021 at 04:47:15PM +0800, Jason Wang wrote:
> > > We can open up to ~0U file descriptors, I don't see why we need to
> > > restrict
> > > it in uAPI.
> > There are significan
On Wed, Jun 02, 2021 at 04:15:07PM +1000, David Gibson wrote:
> Is there a compelling reason to have all the IOASIDs handled by one
> FD?
There was an answer on this, if every PASID needs an IOASID then there
are too many FDs.
It is difficult to share the get_user_pages cache across FDs.
There
On Wed, 2 Jun 2021 13:01:40 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 02:20:15AM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Wednesday, June 2, 2021 6:22 AM
> > >
> > > On Tue, 1 Jun 2021 07:01:57 +
> > > "Tian, Kevin" wrote:
> > > >
> > > > I summarize
On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > /* Bind guest I/O page table */
> > > bind_data = {
> > > .ioasid = gva_ioasid;
> > > .addr = gva_pgtable1;
> > > // and format information
> > > };
> > > ioctl(ioasid_fd, IOASID_BIND_PGTABL
From: Rob Clark
Add, via the adreno-smmu-priv interface, a way for the GPU to request
the SMMU to stall translation on faults, and then later resume the
translation, either retrying or terminating the current translation.
This will be used on the GPU side to "freeze" the GPU while we snapshot
us
From: Jordan Crouse
Add a callback in adreno-smmu-priv to read interesting SMMU
registers to provide an opportunity for a richer debug experience
in the GPU driver.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 17
drivers/
From: Jordan Crouse
Call report_iommu_fault() to allow upper-level drivers to register their
own fault handlers.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers
From: Rob Clark
(Resend, first attempt seems to not have entirely shown up in patchwork
and had a random already merged patch tagging along because 00*patch
picks up things I forgot to delete)
This picks up an earlier series[1] from Jordan, and adds additional
support needed to generate GPU devc
On Wed, Jun 02, 2021 at 04:57:52PM +1000, David Gibson wrote:
> I don't think presence or absence of a group fd makes a lot of
> difference to this design. Having a group fd just means we attach
> groups to the ioasid instead of individual devices, and we no longer
> need the bookkeeping of "part
On Wed, Jun 02, 2021 at 04:32:27PM +1000, David Gibson wrote:
> > I agree with Jean-Philippe - at the very least erasing this
> > information needs a major rational - but I don't really see why it
> > must be erased? The HW reports the originating device, is it just a
> > matter of labeling the dev
On Wed, Jun 02, 2021 at 01:33:22AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, June 2, 2021 1:42 AM
> >
> > On Tue, Jun 01, 2021 at 08:10:14AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Saturday, May 29, 2021 1:36 AM
> > > >
> > > > On Thu,
On Wed, Jun 02, 2021 at 04:52:02PM +0800, Jason Wang wrote:
>
> 在 2021/6/2 上午4:28, Jason Gunthorpe 写道:
> > > I summarized five opens here, about:
> > >
> > > 1) Finalizing the name to replace /dev/ioasid;
> > > 2) Whether one device is allowed to bind to multiple IOASID fd's;
> > > 3) Carry de
On 6/2/21 11:01 AM, Tianyu Lan wrote:
> Hi Boris:
> Thanks for your review.
>
> On 6/2/2021 9:16 AM, Boris Ostrovsky wrote:
>>
>> On 5/30/21 11:06 AM, Tianyu Lan wrote:
>>> @@ -91,6 +92,6 @@ int pci_xen_swiotlb_init_late(void)
>>> EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
>>> IOMMU_I
On Wed, Jun 02, 2021 at 02:20:15AM +, Tian, Kevin wrote:
> > From: Alex Williamson
> > Sent: Wednesday, June 2, 2021 6:22 AM
> >
> > On Tue, 1 Jun 2021 07:01:57 +
> > "Tian, Kevin" wrote:
> > >
> > > I summarized five opens here, about:
> > >
> > > 1) Finalizing the name to replace /dev
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the relation between virtio-iommu and the endpoints
it manages.
Three steps are needed to configure DMA of endpoints:
(1) acpi_viot_init(): par
Passing a 64-bit address width to iommu_setup_dma_ops() is valid on
virtual platforms, but isn't currently possible. The overflow check in
iommu_dma_init_domain() prevents this even when @dma_base isn't 0. Pass
a limit address instead of a size, so callers don't have to fake a size
to work around t
dma-iommu uses the address bounds described in domain->geometry during
IOVA allocation. The address size parameters of iommu_setup_dma_ops()
are useful for describing additional limits set by the platform
firmware, but aren't needed for drivers that call this function from
probe_finalize(). The bas
With the VIOT support in place, x86 platforms can now use the
virtio-iommu.
Because the other x86 IOMMU drivers aren't yet ready to use the
acpi_dma_setup() path, x86 doesn't implement arch_setup_dma_ops() at the
moment. Similarly to Vt-d and AMD IOMMU, call iommu_setup_dma_ops() from
probe_finali
Extract the code that sets up the IOMMU infrastructure from IORT, since
it can be reused by VIOT. Move it one level up into a new
acpi_iommu_configure_id() function, which calls the IORT parsing
function which in turn calls the acpi_iommu_fwspec_init() helper.
Signed-off-by: Jean-Philippe Brucker
Extract generic DMA setup code out of IORT, so it can be reused by VIOT.
Keep it in drivers/acpi/arm64 for now, since it could break x86
platforms that haven't run this code so far, if they have invalid
tables.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64/Makefile | 1 +
include/
Add a driver for the ACPI VIOT table, which provides topology
information for para-virtual IOMMUs. Enable virtio-iommu on
non-devicetree platforms, including x86.
Since v2 [1] I tried to improve commit messages and comments. More
feedback and review are always welcome. Joerg offered to take this
s
Hi Boris:
Thanks for your review.
On 6/2/2021 9:16 AM, Boris Ostrovsky wrote:
On 5/30/21 11:06 AM, Tianyu Lan wrote:
@@ -91,6 +92,6 @@ int pci_xen_swiotlb_init_late(void)
EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
IOMMU_INIT_FINISH(2,
- NULL,
+
On 02/06/2021 16:58, Thierry Reding wrote:
> On Wed, Jun 02, 2021 at 12:40:49PM +0100, Will Deacon wrote:
>> On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote:
>>> On 02/06/2021 10:52, Thierry Reding wrote:
On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
On 02/06/2021 16:53, Thierry Reding wrote:
> On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2021 10:52, Thierry Reding wrote:
>>> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
> On 01/0
On Wed, Jun 02, 2021 at 12:40:49PM +0100, Will Deacon wrote:
> On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote:
> > On 02/06/2021 10:52, Thierry Reding wrote:
> > > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
> > >> On 02/06/2021 09:33, Krzysztof Kozlows
On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote:
> On 02/06/2021 10:52, Thierry Reding wrote:
> > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
> >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
> >>> On 01/06/2021 20:08, Thierry Reding wrote:
> On
On 2021-06-02 09:09, Daniel Borkmann wrote:
On 6/1/21 7:42 PM, Jussi Maki wrote:
Hi Robin,
On Tue, Jun 1, 2021 at 2:39 PM Robin Murphy wrote:
The regression shows as a significant drop in throughput as measured
with "super_netperf" [0],
with measured bandwidth of ~95Gbps before and ~35Gbps af
> From: Enrico Weigelt, metux IT consult
> Sent: Wednesday, June 2, 2021 2:09 PM
>
> On 31.05.21 19:37, Parav Pandit wrote:
>
> > It appears that this is only to make map ioctl faster apart from accounting.
> > It doesn't have any ioasid handle input either.
> >
> > In that case, can it be a n
On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote:
> On 02/06/2021 10:52, Thierry Reding wrote:
> > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
> >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
> >>> On 01/06/2021 20:08, Thierry Reding wrote:
> On
On 02/06/2021 10:52, Thierry Reding wrote:
> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
>>> On 01/06/2021 20:08, Thierry Reding wrote:
On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
> On Fri, May 28,
On Wed, Jun 02 2021 at 12:14, Borislav Petkov wrote:
> On Sat, May 29, 2021 at 11:17:30AM +0200, Thomas Gleixner wrote:
>> --- a/arch/x86/include/asm/disabled-features.h
>> +++ b/arch/x86/include/asm/disabled-features.h
>> @@ -56,11 +56,8 @@
>> # define DISABLE_PTI(1 << (X86_FEATU
On Sat, May 29, 2021 at 11:17:30AM +0200, Thomas Gleixner wrote:
> --- a/arch/x86/include/asm/disabled-features.h
> +++ b/arch/x86/include/asm/disabled-features.h
> @@ -56,11 +56,8 @@
> # define DISABLE_PTI (1 << (X86_FEATURE_PTI & 31))
> #endif
>
> -#ifdef CONFIG_IOMMU_SUPPORT
> -# def
在 2021/6/2 上午1:29, Jason Gunthorpe 写道:
On Tue, Jun 01, 2021 at 02:07:05PM +0800, Jason Wang wrote:
For the case of 1M, I would like to know what's the use case for a single
process to handle 1M+ address spaces?
For some scenarios every guest PASID will require a IOASID ID # so
there is a larg
On 27.05.21 09:58, Tian, Kevin wrote:
Hi,
/dev/ioasid provides an unified interface for managing I/O page tables for
devices assigned to userspace. Device passthrough frameworks (VFIO, vDPA,
etc.) are expected to use this interface instead of creating their own logic to
isolate untrusted device
On 31.05.21 19:37, Parav Pandit wrote:
It appears that this is only to make map ioctl faster apart from accounting.
It doesn't have any ioasid handle input either.
In that case, can it be a new system call? Why does it have to be under
/dev/ioasid?
For example few years back such system call m
在 2021/6/2 上午1:31, Jason Gunthorpe 写道:
On Tue, Jun 01, 2021 at 04:47:15PM +0800, Jason Wang wrote:
We can open up to ~0U file descriptors, I don't see why we need to restrict
it in uAPI.
There are significant problems with such large file descriptor
tables. High FD numbers man things like s
在 2021/6/2 上午4:28, Jason Gunthorpe 写道:
I summarized five opens here, about:
1) Finalizing the name to replace /dev/ioasid;
2) Whether one device is allowed to bind to multiple IOASID fd's;
3) Carry device information in invalidation/fault reporting uAPI;
4) What should/could be specified wh
On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
> > On 01/06/2021 20:08, Thierry Reding wrote:
> >> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
> >>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrot
On 6/1/21 7:42 PM, Jussi Maki wrote:
Hi Robin,
On Tue, Jun 1, 2021 at 2:39 PM Robin Murphy wrote:
The regression shows as a significant drop in throughput as measured
with "super_netperf" [0],
with measured bandwidth of ~95Gbps before and ~35Gbps after:
I guess that must be the difference be
On 02/06/2021 05:37, Lu Baolu wrote:
On 6/1/21 10:29 PM, John Garry wrote:
For streaming DMA mappings involving an IOMMU and whose IOVA len
regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This is much more pronounced from commit 4e8
On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
> On 01/06/2021 20:08, Thierry Reding wrote:
>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
>
On 01/06/2021 20:08, Thierry Reding wrote:
> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
From: Thierry Reding
Hi,
this is
On Fri, May 28, 2021 at 08:36:49PM -0300, Jason Gunthorpe wrote:
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
>
> > 2.1. /dev/ioasid uAPI
> > +
> >
> > /*
> > * Check whether an uAPI extension is supported.
> > *
> > * This is for FD-level capabilities, su
1 - 100 of 104 matches
Mail list logo
