On Wed, Nov 02, 2022 at 09:51:56AM -0300, Jason Gunthorpe wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git tags/for-joerg
Pulled, thanks Jason and Nicolin.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
On Fri, Jan 06, 2023 at 01:24:11PM -0400, Jason Gunthorpe wrote:
> I think it is just better to follow kernel convention and have
> allocation functions include the GFP because it is a clear signal to
> the user that there is an allocation hidden inside the API. The whole
> point of gfp is not to h
On Fri, Jan 20, 2023 at 01:53:40PM -0400, Jason Gunthorpe wrote:
> > Well, having GFP parameters is not a strict kernel convention. There are
> > places doing it differently and have sleeping and atomic variants of
> > APIs. I have to say I like the latter more. But given that this leads to
> > an
On Mon, Jan 23, 2023 at 04:35:53PM -0400, Jason Gunthorpe wrote:
> Jason Gunthorpe (10):
> iommu: Add a gfp parameter to iommu_map()
> iommu: Remove iommu_map_atomic()
> iommu: Add a gfp parameter to iommu_map_sg()
> iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
>
On Mon, Aug 01, 2022 at 07:51:42PM +0300, Andy Shevchenko wrote:
> drivers/iommu/virtio-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://li
On Mon, Aug 15, 2022 at 11:14:33AM -0700, Nicolin Chen wrote:
> Provide a dedicated errno from the IOMMU driver during attach that the
> reason attached failed is because of domain incompatability. EMEDIUMTYPE
> is chosen because it is never used within the iommu subsystem today and
> evokes a sens
On Thu, Aug 25, 2022 at 04:46:24PM +0100, Jean-Philippe Brucker wrote:
> Cc: sta...@vger.kernel.org
> Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence")
> Signed-off-by: Jean-Philippe Brucker
> ---
> Since v2 [1], I tried to refine the commit message.
> This fix is need
On Wed, Sep 07, 2022 at 10:47:39AM -0300, Jason Gunthorpe wrote:
> Would you be happier if we wrote it like
>
> #define IOMMU_EINCOMPATIBLE_DEVICE xx
>
> Which tells "which of the function parameters is actually invalid" ?
Having done some Rust hacking in the last months, I have to say I like
t
From: Joerg Roedel
A recent fix introduced viommu_capable() but other changes
from Robin change the function signature of the call-back it
is used for.
When both changes are merged a compile error will happen
because the function pointer types mismatch. Fix that by
updating the viommu_capable
On Wed, Sep 07, 2022 at 02:10:33PM -0300, Jason Gunthorpe wrote:
> Sure, rust has all sorts of nice things. But the kernel doesn't follow
> rust idioms, and I don't think this is a great place to start
> experimenting with them.
It is actually a great place to start experimenting. The IOMMU
interf
Hi Nicolin,
On Fri, Sep 23, 2022 at 12:16:29AM -0700, Nicolin Chen wrote:
> This series is to replace the previous EMEDIUMTYPE patch in a VFIO series:
> https://lore.kernel.org/kvm/yxnt9uqtmbqul...@8bytes.org/
\o/
> Nicolin Chen (5):
> iommu/amd: Drop unnecessary checks in amd_iommu_attach_dev
Hi Christoph,
On Thu, Jan 10, 2019 at 02:59:52PM +0100, Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 02:44:30PM +0100, Joerg Roedel wrote:
> > The problem is a limitation of the SWIOTLB implementation,
> > which does not support allocations larger than 256kb. When
> >
From: Joerg Roedel
The SWIOTLB implementation has a maximum size it can
allocate dma-handles for. This needs to be exported so that
device drivers don't try to allocate larger chunks.
This is especially important for block device drivers like
virtio-blk, that might do DMA through SW
From: Joerg Roedel
Segments can't be larger than the maximum DMA allocation
size supported by virtio on the platform. Take that into
account when setting the maximum segment size for a block
device.
Signed-off-by: Joerg Roedel
---
drivers/block/virtio_blk.c | 10 ++
1 file chang
SWIOTLB bounce buffering and limits the
maximum segment size in the virtio-blk driver in this case,
so that it doesn't try to do larger reads/writes.
Please review.
Thanks,
Joerg
Joerg Roedel (3):
swiotlb: Export maximum allocation size
virtio: Introduce virtio_max_dma_size()
virti
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map.
The functions return the
On Mon, Jan 14, 2019 at 01:20:45PM -0500, Michael S. Tsirkin wrote:
> Which would be fine especially if we can manage not to introduce a bunch
> of indirect calls all over the place and hurt performance.
Which indirect calls? In case of unset dma_ops the DMA-API functions
call directly into the dm
From: Joerg Roedel
The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 5 +
kernel/dma/swiotlb.c| 5 +
2 files changed
From: Joerg Roedel
Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.
Signed-off-by: Joerg Roedel
---
drivers/block/virtio_blk.c | 10 ++
1 file changed, 6 inser
Christoph Hellwig.
Please review.
Thanks,
Joerg
Joerg Roedel (3):
swiotlb: Introduce swiotlb_max_mapping_size()
dma: Introduce dma_max_mapping_size()
virtio-blk: Consider dma_max_mapping_size() for maximum segment size
drivers/block/virtio_blk.c | 10 ++
include/linux
On Tue, Jan 15, 2019 at 02:37:54PM +0100, Christoph Hellwig wrote:
> > +size_t dma_direct_max_mapping_size(struct device *dev)
> > +{
> > + /*
> > +* Return the minimum of the direct DMA limit and the SWIOTLB limit.
> > +* Since direct DMA has no limit, it is fine to just return the SWIOT
From: Joerg Roedel
The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.
Signed-off-by: Joerg Roedel
---
include/linux/dma
On Wed, Jan 16, 2019 at 09:05:40AM -0500, Michael S. Tsirkin wrote:
> On Tue, Jan 15, 2019 at 02:22:57PM +0100, Joerg Roedel wrote:
> > + max_size = dma_max_mapping_size(&vdev->dev);
> > +
>
>
> Should this be limited to ACCESS_PLATFORM?
>
> I see no reas
On Thu, Jan 10, 2019 at 12:02:05PM -0500, Konrad Rzeszutek Wilk wrote:
> Why not use swiotlb_nr_tbl ? That is how drivers/gpu/drm use to figure if they
> need to limit the size of pages.
That function just exports the overall size of the swiotlb aperture, no?
What I need here is the maximum size f
On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
> Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
> all virtio devices under AMD-SEV guests?
Yes, that is correct. Emulated DMA can only happen on the SWIOTLB
aperture, because that memory is not encrypted. The g
Hi Jean-Philippe,
On Thu, Dec 13, 2018 at 12:50:29PM +, Jean-Philippe Brucker wrote:
> We already do deferred flush: UNMAP requests are added to the queue by
> iommu_unmap(), and then flushed out by iotlb_sync(). So we switch to the
> host only on iotlb_sync(), or when the request queue is ful
Hi Jean-Philippe,
thanks for all your hard work on this!
On Tue, Jan 15, 2019 at 12:19:52PM +, Jean-Philippe Brucker wrote:
> Implement the virtio-iommu driver, following specification v0.9 [1].
To make progress on this I think the spec needs to be close to something
that can be included int
From: Joerg Roedel
This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 5 +
2 files changed, 11 insertions(+)
diff --git a/include/linux
From: Joerg Roedel
The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 5 +
kernel/dma/swiotlb.c| 5 +
2 files changed
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API
From: Joerg Roedel
The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.
Signed-off-by: Joerg Roedel
---
include/linux/dma
limit in
dma_direct_max_mapping_size()
* Only apply the maximum segment limit in virtio-blk when
DMA-API is used for the vring
Please review.
Thanks,
Joerg
Joerg Roedel (5):
swiotlb: Introduce swiotlb_max_mapping_size()
swiotlb: Add is_swiotlb_active
From: Joerg Roedel
Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.
Signed-off-by: Joerg Roedel
---
drivers/block/virtio_blk.c | 10 ++
1 file changed, 6 inser
On Wed, Jan 23, 2019 at 10:28:13PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:45PM +0100, Joerg Roedel wrote:
> > +extern size_t swiotlb_max_mapping_size(struct device *dev);
>
> No need for the extern keyword on function declarations in headers.
Right
On Wed, Jan 23, 2019 at 10:27:55PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:46PM +0100, Joerg Roedel wrote:
> > +bool is_swiotlb_active(void)
> > +{
> > + return !no_iotlb_memory;
> > +}
>
> As I've just introduced and fixed a bug i
On Wed, Jan 23, 2019 at 10:31:39PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:49PM +0100, Joerg Roedel wrote:
> > + max_size = virtio_max_dma_size(vdev);
> > +
> > /* Host can optionally specify maximum segment size and number of
> >
On Thu, Jan 24, 2019 at 09:42:21AM +0100, Christoph Hellwig wrote:
> Yes. But more importantly it would fix the limit for all other block
> drivers that set large segment sizes when running over swiotlb.
True, so it would be something like the diff below? I havn't worked on
the block layer, so I
On Thu, Jan 24, 2019 at 09:41:07AM +0100, Christoph Hellwig wrote:
> On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote:
> > > As I've just introduced and fixed a bug in this area in the current
> > > cycle - I don't think no_iotlb_memory is what your want
From: Joerg Roedel
This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 9 +
2 files changed, 15
From: Joerg Roedel
The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Joerg
From: Joerg Roedel
The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 5 +
kernel/dma
From: Joerg Roedel
Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Joerg Roedel
---
drivers/block/virtio_blk.c
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API
reported.
For all changes to v3, a diff to v3 of the patch-set is at
the end of this email.
Please review.
Thanks,
Joerg
Joerg Roedel (5):
swiotlb: Introduce swiotlb_max_mapping_size()
swiotlb: Add is_swiotlb_active() function
dma: Introduce dma_max_mapping_size()
virtio: Introduce
From: Joerg Roedel
The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API
From: Joerg Roedel
Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
dr
Hi Tom,
On Wed, Jan 30, 2019 at 03:10:29PM +, Lendacky, Thomas wrote:
> On 1/29/19 2:43 AM, Joerg Roedel wrote:
> > +size_t virtio_max_dma_size(struct virtio_device *vdev)
> > +{
> > + size_t max_segment_size = SIZE_MAX;
> > +
> &g
larger than that, the
allocation of the dma-handle fails and an IO error is reported.
Changes to v4 are:
- Added Reviewed-by tags from Christoph
- Added missing EXPORT_SYMBOL(_GPL) lines
Please review.
Thanks,
Joerg
Joerg Roedel (5):
swiotlb: Introduce
From: Joerg Roedel
The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux
From: Joerg Roedel
This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 9
From: Joerg Roedel
This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 9
allocations larger than 256kb. When the
virtio-blk driver tries to read/write a block larger than that, the
allocation of the dma-handle fails and an IO error is reported.
Changes to v5 are:
- Changed patch 3 to uninline dma_max_mapping_size()
Please review.
Thanks,
Joerg
Joerg Roedel
From: Joerg Roedel
The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux
From: Joerg Roedel
The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API
From: Joerg Roedel
Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
dr
On Thu, Jan 31, 2019 at 09:43:51AM -0500, Michael S. Tsirkin wrote:
> OK. Joerg can you repost the series with this squashed
> and all acks applied?
Sure, sent out now as v6.
Regards,
Joerg
___
Virtualization mailing list
Virtualization@lists.l
patch-set.
Michael, feel free to either apply this on-top of the patch-set or merge
the diff into patch 3, whatever you prefer.
>From 2bb95d2136280c79de9553852ee3370f6d42d7b3 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Thu, 31 Jan 2019 13:55:27 +0100
Subject: [PATCH] dma: Uninline dma_max_
Hi Michael,
On Tue, Feb 05, 2019 at 03:52:38PM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 31, 2019 at 05:33:58PM +0100, Joerg Roedel wrote:
> > Changes to v5 are:
> >
> > - Changed patch 3 to uninline dma_max_mapping_size()
>
> And this lead to problems re
On Thu, Feb 07, 2019 at 09:46:13AM +0100, Joerg Roedel wrote:
> Hmm, I didn't get any kbuild emails for this series. Can you please
> forward it me so that I can look into it?
Nevermind, just found them in another inbox.
From: Joerg Roedel
The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux
CONFIG_SWIOTLB=n
Please review.
Thanks,
Joerg
Joerg Roedel (5):
swiotlb: Introduce swiotlb_max_mapping_size()
swiotlb: Add is_swiotlb_active() function
dma: Introduce dma_max_mapping_size()
virtio: Introduce virtio_max_dma_size()
virtio-blk: Consider virtio_max_dma_size() for
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API
From: Joerg Roedel
The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by
From: Joerg Roedel
Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
dr
From: Joerg Roedel
This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 9
e the Spec was
not yet official.
So for the code:
Acked-by: Joerg Roedel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Hi,
On Sun, Jun 23, 2019 at 11:19:45PM -0700, Christoph Hellwig wrote:
> Joerg, any chance you could review this? Toms patches to convert the
> AMD and Intel IOMMU drivers to the dma-iommu code are going to make my
> life in DMA land significantly easier, so I have a vested interest
> in
On Mon, Jul 22, 2019 at 11:16:08AM -0400, Michael S. Tsirkin wrote:
> I'm merging this for this release, unless someone objects.
No objections from me.
Acked-by: Joerg Roedel
___
Virtualization mailing list
Virtualization@lists.linux-founda
Hi,
to make progress on this, we should first agree on the protocol used
between guest and host. I have a few points to discuss on the protocol
first.
On Tue, Dec 11, 2018 at 06:20:57PM +, Jean-Philippe Brucker wrote:
> [1] Virtio-iommu specification v0.9, sources and pdf
> git://linux-ar
On Thu, Oct 29, 2015 at 11:01:41AM +0200, Michael S. Tsirkin wrote:
> Example: you have a mix of assigned devices and virtio devices. You
> don't trust your assigned device vendor not to corrupt your memory so
> you want to limit the damage your assigned device can do to your guest,
> so you use an
On Fri, Oct 30, 2015 at 02:20:35PM +0100, Christian Borntraeger wrote:
> +static void *dma_noop_alloc(struct device *dev, size_t size,
> + dma_addr_t *dma_handle, gfp_t gfp,
> + struct dma_attrs *attrs)
> +{
> + void *ret;
> +
> + ret = (void
---
> 1 file changed, 4 insertions(+), 42 deletions(-)
Reviewed-by: Joerg Roedel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
-
> arch/s390/include/asm/dma-mapping.h | 6 --
> arch/s390/pci/pci.c | 1 +
> arch/s390/pci/pci_dma.c | 4 ++--
> 5 files changed, 14 insertions(+), 6 deletions(-)
Reviewed-by: Joerg Roedel
___
Virtualizati
f-by: Christian Borntraeger
> ---
> include/linux/dma-mapping.h | 2 ++
> lib/Makefile| 1 +
> lib/dma-noop.c | 75
> +
> 3 files changed, 78 insertions(+)
> create mode 100644 lib/d
On Sun, Nov 08, 2015 at 12:37:47PM +0200, Michael S. Tsirkin wrote:
> I have no problem with that. For example, can we teach
> the DMA API on intel x86 to use PT for virtio by default?
> That would allow merging Andy's patches with
> full compatibility with old guests and hosts.
Well, the only inc
On Tue, Nov 10, 2015 at 01:04:36PM +1100, Benjamin Herrenschmidt wrote:
> The "in absence of the new DT binding" doesn't make that much sense.
>
> Those platforms use device-trees defined since the dawn of ages by
> actual open firmware implementations, they either have no iommu
> representation i
On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
> One correction: it's a feature of the device in the system.
> There could be a mix of devices bypassing and not
> bypassing the IOMMU.
No, it really is not. A device can't chose to bypass the IOMMU. But the
IOMMU can chose to le
On Wed, Apr 27, 2016 at 05:34:30PM +0300, Michael S. Tsirkin wrote:
> On Wed, Apr 27, 2016 at 04:23:32PM +0200, Joerg Roedel wrote:
> QEMU can choose to bypass IOMMU for one device and not the other.
> IOMMU in QEMU isn't involved when it's bypassed.
And it is QEMU's ta
On Wed, Apr 27, 2016 at 05:54:57PM +0300, Michael S. Tsirkin wrote:
> Point is, QEMU is not the only virtio implementation out there.
> So we can't know no virtio implementations have an IOMMU as long as
> linux supports this IOMMU.
> virtio always used physical addresses since it was born and if i
On Sun, Sep 08, 2019 at 09:56:36AM -0700, Tom Murphy wrote:
> Convert the AMD iommu driver to the dma-iommu api. Remove the iova
> handling and reserve region code from the AMD iommu driver.
Applied, thanks. Note that it will not show up in linux-next before
-rc3.
_
On Fri, Oct 25, 2019 at 01:13:40PM -0300, Cristiane Naves wrote:
> Remove the variable of return. Issue found by
> coccicheck(scripts/coccinelle/misc/returnvar.cocci)
>
> Signed-off-by: Cristiane Naves
> ---
> drivers/iommu/virtio-iommu.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Hi Thierry
On Mon, Dec 09, 2019 at 03:50:02PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Most IOMMU drivers only need to free the memory allocated for each
> reserved region. Instead of open-coding the loop to do this in each
> driver, extract the code into a common function that ca
On Thu, Dec 19, 2019 at 01:47:47PM +0100, Thierry Reding wrote:
> On Thu, Dec 19, 2019 at 09:53:22AM +0800, Lu Baolu wrote:
> > Please tweak the title to
> >
> > "iommu/vt-d: Use generic_iommu_put_resv_regions()"
> >
> > then,
> >
> > Acked-by: Lu Baolu
> >
> > Best regards,
> > baolu
>
> Joe
Signed-off-by: Tom Lendacky
[ jroe...@suse.de: Adapt to VC handling framework ]
Co-developed-by: Joerg Roedel
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/sev-es.c | 8 +
arch/x86/include/uapi/asm/svm.h | 5 +
arch/x86/kernel/sev-es-shared.c | 236
From: Joerg Roedel
The function can fail to create an identity mapping, check for that
and bail out if it happens.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/ident_map_64.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed
From: Tom Lendacky
Add support for decoding and handling #VC exceptions for IOIO events.
Signed-off-by: Tom Lendacky
[ jroe...@suse.de: Adapted code to #VC handling framework ]
Co-developed-by: Joerg Roedel
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/sev-es.c | 3 +
arch/x86
From: Joerg Roedel
Setup an early handler for #VC exceptions. There is no GHCB mapped
yet, so just re-use the no_ghcb_vc_handler. It can only handle CPUID
exit-codes, but that should be enough to get the kernel through
verify_cpu() and __startup_64() until it runs on virtual addresses.
Signed
From: Joerg Roedel
Reload the GDT after switching to virtual addresses to make sure it will
not go away when the lower mappings are removed.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/head_64.S | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/head_64.S b/arch/x86
From: Tom Lendacky
Add CPU feature detection for Secure Encrypted Virtualization with
Encrypted State. This feature enhances SEV by also encrypting the
guest register state, making it in-accessible to the hypervisor.
Signed-off-by: Tom Lendacky
Signed-off-by: Joerg Roedel
---
arch/x86
From: Joerg Roedel
With SEV-ES, exception handling is needed very early, even before the
kernel has cleared the bss segment. In order to prevent clearing the
currently used IDT, move the IDT to the data segment.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/idt.c | 2 +-
1 file changed, 1
From: Joerg Roedel
Setup sev-es.c and include the code from the
pre-decompression stage to also build it into the image of the running
kernel. Temporarily add __maybe_unused annotations to avoid build
warnings until the functions get used.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel
From: Joerg Roedel
Move the definition of x86 trap vector numbers and the page-fault
error code bits to the new header file asm/trap_defs.h. This makes it
easier to include them into pre-decompression boot code. No functional
changes.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm
From: Joerg Roedel
In the CONFIG_X86_VERBOSE_BOOTUP=Y case the debug_puthex() macro just
turns into __puthex, which takes 'unsigned long' as parameter. But in
the CONFIG_X86_VERBOSE_BOOTUP=N case it is a function which takes
'unsigned char *', causing compile warnings when
From: Joerg Roedel
Add the first handler for #VC exceptions. At stage 1 there is no GHCB
yet becaue we might still be on the EFI page table and thus can't map
memory unencrypted.
The stage 1 handler is limited to the MSR based protocol to talk to
the hypervisor and can only support CPUID
From: Joerg Roedel
Changing the function to take start and end as parameters instead of
start and size simplifies the callers, which don't need to calculate
the size if they already have start and end.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/ident_map_64.c
From: Joerg Roedel
Call set_sev_encryption_mask() while still on the stage 1 #VC-handler,
because the stage 2 handler needs our own page-tables to be set up, to
which calling set_sev_encryption_mask() is a prerequisite.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/head_64.S
From: Joerg Roedel
Install an exception handler for #VC exception that uses a GHCB. Also
add the infrastructure for handling different exit-codes by decoding
the instruction that caused the exception and error handling.
Signed-off-by: Joerg Roedel
---
arch/x86/Kconfig
From: Joerg Roedel
The inat-tables.c file has some arrays in it that contain pointers to
other arrays. These pointers need to be relocated when the kernel
image is moved to a different location.
The pre-decompression boot-code has no support for applying ELF
relocations, so initialize these
201 - 300 of 1087 matches
Mail list logo
