On Mon, 28 Mar 2022 08:37:23 +0200
Christoph Hellwig wrote:
> On Fri, Mar 25, 2022 at 11:46:09AM -0700, Linus Torvalds wrote:
> > I think my list of three different sync cases (not just two! It's not
> > just about whether to sync for the CPU or the device, it's also about
> > what direction the
On Sun, 27 Mar 2022 17:30:01 -0700
Linus Torvalds wrote:
> On Sun, Mar 27, 2022 at 4:52 PM Halil Pasic wrote:
> >
> > I have no intention of pursuing this. When fixing the information leak,
> > I happened to realize, that a somewhat similar situation can emerge when
> &
On Sat, 26 Mar 2022 22:21:03 -0700
Linus Torvalds wrote:
> On Sat, Mar 26, 2022 at 10:06 PM Linus Torvalds
> wrote:
> >
> > On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic wrote:
> > >
> > > I agree it CPU modified buffers *concurrently* with DMA can never wor
On Sat, 26 Mar 2022 22:06:15 -0700
Linus Torvalds wrote:
> On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic wrote:
> >
> > I agree it CPU modified buffers *concurrently* with DMA can never work,
> > and I believe the ownership model was conceived to prevent this
> > situ
On Thu, 24 Mar 2022 12:26:53 -0700
Linus Torvalds wrote:
> So I don't think the dma_sync_single_for_device() is *wrong* per se,
> because the CPU didn't actually do any modifications.
>
> But yes, I think it's unnecessary - because any later CPU accesses
> would need that dma_sync_single_for_cpu
On Fri, 25 Mar 2022 22:13:08 +0100
Johannes Berg wrote:
> > > Then, however, we need to define what happens if you pass
> > > DMA_BIDIRECTIONAL to the sync_for_cpu() and sync_for_device() functions,
> > > which adds two more cases? Or maybe we eventually just think that's not
> > > valid at all,
On Fri, 25 Mar 2022 11:27:41 +
Robin Murphy wrote:
> What muddies the waters a bit is that the opposite combination
> sync_for_cpu(DMA_TO_DEVICE) really *should* always be a no-op, and I for
> one have already made the case for eliding that in code elsewhere, but
> it doesn't necessarily h
On Thu, 24 Mar 2022 19:02:16 +0100
Halil Pasic wrote:
> > I'll admit I still never quite grasped the reason for also adding the
> > override to swiotlb_sync_single_for_device() in aa6f8dcbab47, but I
> > think by that point we were increasingly tired and confused and
On Thu, 24 Mar 2022 16:52:31 +
Robin Murphy wrote:
> > Creating a new mapping for the same buffer before unmapping the
> > previous one does looks rather bogus. But it does not fit the
> > pattern where revering the sync_single changes make the driver
> > work again.
>
> OK, you made me l
On Wed, 23 Mar 2022 20:54:08 +
Robin Murphy wrote:
> On 2022-03-23 19:16, Linus Torvalds wrote:
> > On Wed, Mar 23, 2022 at 12:06 PM Robin Murphy wrote:
> >
> >>
> >> On 2022-03-23 17:27, Linus Torvalds wrote:
> >>>
> >>> I'm assuming that the ath9k issue is that it gives DMA mapping a
t we would have to figure out the starting
address, and the size of the mapping in
swiotlb_sync_single_for_device(). While this does seem possible, there
seems to be no firm consensus on how things are supposed to work.
Signed-off-by: Halil Pasic
Fixes: ddbd89deb7d3 ("swiotlb: fix
On Fri, 4 Mar 2022 17:55:40 +0100
Greg KH wrote:
> On Fri, Mar 04, 2022 at 05:34:47PM +0100, Halil Pasic wrote:
> > On Fri, 4 Mar 2022 15:28:44 +0100
> > Greg KH wrote:
> >
> > > On Fri, Mar 04, 2022 at 02:58:58PM +0100, Halil Pasic wrote:
On Fri, 4 Mar 2022 15:28:44 +0100
Greg KH wrote:
> On Fri, Mar 04, 2022 at 02:58:58PM +0100, Halil Pasic wrote:
> > This reverts commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e.
>
> Why???
TLDR; We got v4 merged instead of v7
>
> > Signed-off-by: Halil Pasic
&g
On Fri, 4 Mar 2022 07:53:48 -0800
Christoph Hellwig wrote:
> On Fri, Mar 04, 2022 at 02:58:57PM +0100, Halil Pasic wrote:
> > Unfortunately, we ended up with the wrong version of the patch "fix info
> > leak with DMA_FROM_DEVICE" getting merged. We got v4 merged, but t
e for this patch, and are likely to be a subject of some
future work.
Signed-off-by: Halil Pasic
Reported-by: Ali Haider
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c b
_device is also required to do an extra bounce
* It was decided that we want to defer introducing DMA_ATTR_OVERWRITE,
until we have exploiters
* And anyway DMA_ATTR_OVERWRITE must take precedence over
DMA_ATTR_SKIP_CPU_SYNC, so the v4 implementation of DMA_ATTR_OVERWRITE
ain't even orrect
This reverts commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e.
Signed-off-by: Halil Pasic
---
Documentation/core-api/dma-attributes.rst | 8
include/linux/dma-mapping.h | 8
kernel/dma/swiotlb.c | 3 +--
3 files changed, 1 insertion(+), 18
On Fri, 23 Jul 2021 20:27:56 -0400
Konrad Rzeszutek Wilk wrote:
> On Sat, Jul 24, 2021 at 01:17:46AM +0200, Halil Pasic wrote:
> > Since commit 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for
> > swiotlb data bouncing") if code sets swiotlb_force it needs to do
;), which ain't exactly broken in its original context,
but could give us some more headache if people backport the broken
change and forget this fix.
Signed-off-by: Halil Pasic
Tested-by: Christian Borntraeger
Reviewed-by: Christian Borntraeger
Fixes: 903cd0f315fe ("swiotlb: Use is_swio
On Fri, 23 Jul 2021 19:53:58 +0200
Christian Borntraeger wrote:
> On 23.07.21 16:01, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jul 23, 2021 at 10:50:57AM +0200, Christian Borntraeger wrote:
> >>
> >>
> >> On 23.07.21 10:47, Halil Pasic wrote:
>
On Fri, 23 Jul 2021 08:14:19 +0200
Christian Borntraeger wrote:
> Resending with the correct email of Heiko
>
> On 23.07.21 03:12, Halil Pasic wrote:
> > On Thu, 22 Jul 2021 21:22:58 +0200
> > Christian Borntraeger wrote:
> >
> >> On 20.07.21 15:38,
does NOT fix this issue, so it seems that
> even more
> things are broken.
>
> Any idea what else might be broken?
I've done some debugging, and I think I know what is going on. Since
that commit we need to set force_swiotlb before the swiotlb itself is
initialized. So the pat
On Fri, 21 Feb 2020 17:36:45 +0100
Christoph Hellwig wrote:
> > By "legacy devices" I assume you mean pre-virtio-1.0 devices, that
> > lack the F_VERSION_1 feature flag. Is that right? Because I don't
> > see how being a legacy device or not relates to use of the DMA API.
>
> No. "legacy"
On Mon, 24 Feb 2020 14:33:14 +1100
David Gibson wrote:
> On Fri, Feb 21, 2020 at 07:07:02PM +0100, Halil Pasic wrote:
> > On Fri, 21 Feb 2020 10:48:15 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Fri, Feb 21, 2020 at 02:06:39PM +0100, Halil Pasic
On Mon, 24 Feb 2020 17:26:20 +0800
Jason Wang wrote:
> That's better.
>
> How about attached?
>
> Thanks
Thanks Jason! It does avoid the translation overhead in vhost.
Tested-by: Halil Pasic
Regarding the code, you fence it in virtio-net.c, but AFAIU this feature
has
On Fri, 21 Feb 2020 17:39:38 +0100
Christoph Hellwig wrote:
> On Fri, Feb 21, 2020 at 03:33:40PM +0100, Halil Pasic wrote:
> > > Hell no. This is a detail of the platform DMA direct implementation.
> >
> > I beg to differ. If it was a detail of the DMA direct implementa
On Fri, 21 Feb 2020 10:48:15 -0500
"Michael S. Tsirkin" wrote:
> On Fri, Feb 21, 2020 at 02:06:39PM +0100, Halil Pasic wrote:
> > On Fri, 21 Feb 2020 14:27:27 +1100
> > David Gibson wrote:
> >
> > > On Thu, Feb 20, 2020 at 05:31:35PM +0100, Christoph Hel
On Fri, 21 Feb 2020 10:56:45 -0500
"Michael S. Tsirkin" wrote:
> On Fri, Feb 21, 2020 at 02:12:30PM +0100, Halil Pasic wrote:
> > On Thu, 20 Feb 2020 15:55:14 -0500
> > "Michael S. Tsirkin" wrote:
[..]
> > > To summarize, the necessary conditions f
On Fri, 21 Feb 2020 14:22:26 +0800
Jason Wang wrote:
>
> On 2020/2/21 上午12:06, Halil Pasic wrote:
> > Currently if one intends to run a memory protection enabled VM with
> > virtio devices and linux as the guest OS, one needs to specify the
> > VIRTIO_F_IOMMU_PLATF
On Thu, 20 Feb 2020 17:13:09 +0100
Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index 867c7ebd3f10..fafc8f924955 100644
> > --- a/drivers/virtio/vi
On Thu, 20 Feb 2020 16:33:35 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote:
> > For vhost-net the feature VIRTIO_F_IOMMU_PLATFORM has the following side
> > effect The vhost code assumes it the addresses on the virtio de
On Thu, 20 Feb 2020 16:29:50 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote:
> > * This usage is not congruent with standardised semantics of
> > VIRTIO_F_IOMMU_PLATFORM. Guest memory protected is an orthogonal reason
On Fri, 21 Feb 2020 11:41:57 +0800
Jason Wang wrote:
> > I *think* what you are suggesting here is that virtio devices that
> > have !F_IOMMU_PLATFORM should have their dma_ops set up so that the
> > DMA API treats IOVA==PA, which will satisfy what the device expects.
>
>
> Can this work for
On Fri, 21 Feb 2020 13:59:15 +1100
David Gibson wrote:
> On Thu, Feb 20, 2020 at 05:13:09PM +0100, Christoph Hellwig wrote:
> > On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> &
On Thu, 20 Feb 2020 15:55:14 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
> > Currently the advanced guest memory protection technologies (AMD SEV,
> > powerpc secure guest technology and s390
On Fri, 21 Feb 2020 14:27:27 +1100
David Gibson wrote:
> On Thu, Feb 20, 2020 at 05:31:35PM +0100, Christoph Hellwig wrote:
> > On Thu, Feb 20, 2020 at 05:23:20PM +0100, Christian Borntraeger wrote:
> > > >From a users perspective it makes absolutely perfect sense to use the
> > > bounce buffers
ot;vhost: new device IOTLB API".) On s390 this results in severe
performance degradation (c.a. factor 10). BTW with ccw I/O there is
(architecturally) no IOMMU, so the whole address translation makes no
sense in the context of virtio-ccw.
Halil Pasic (2):
mm: move force_dma_unencrypted() to
-v1.1-cs01.html#x1-416
(In the spec VIRTIO_F_IOMMU_PLATFORM is called
VIRTIO_F_ACCESS_PLATFORM).
Signed-off-by: Halil Pasic
Tested-by: Ram Pai
Tested-by: Michael Mueller
---
include/linux/dma-direct.h | 9 -
include/linux/mem_encrypt.h | 10 ++
2 files changed, 10 insert
t may run with protection. This is
especially interesting for s390 as VIRTIO_F_IOMMU_PLATFORM pushes all
the virtio control structures into the first 2G of guest memory:
something we don't necessarily want to do per-default.
Signed-off-by: Halil Pasic
Tested-by: Ram Pai
Tested-by: Micha
On Thu, 26 Sep 2019 14:04:13 +0100
Robin Murphy wrote:
> On 26/09/2019 13:37, Halil Pasic wrote:
> > On Mon, 23 Sep 2019 17:21:17 +0200
> > Christoph Hellwig wrote:
> >
> >> On Mon, Sep 23, 2019 at 02:34:16PM +0200, Halil Pasic wrote:
> >>> Befor
On Mon, 23 Sep 2019 17:21:17 +0200
Christoph Hellwig wrote:
> On Mon, Sep 23, 2019 at 02:34:16PM +0200, Halil Pasic wrote:
> > Before commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in
> > common code") tweaking the client code supplied GFP_* flags used to b
just not clear any GFP flags at
all but, I decided to be conservative and change only what really needs
to be changed.
I'm not perfectly satisfied with this solution, but I believe it is good
enough, and I can't think of anything better at the moment. Ideas
welcome.
Halil Pasic
need do be 31 addressable because of the 31 bit heritage.
Signed-off-by: Halil Pasic
Reported-by: Marc Hartmayer
Fixes: 37db8985b211 ("s390/cio: add basic protected virtualization support")
---
I was conservative about preserving old behavior for PCI. Could we just
not clear any flags in
encounter silly GFP_* flags. The guys caring
about the respective client code will hopefully fix these soon.
Signed-off-by: Halil Pasic
---
I'm not too happy with my warning message. Suggestions welcome!
---
include/linux/dma-mapping.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
o be a non-issue, we used to allocate those chunks from ZONE_DMA.
Currently our only option with the DMA API is to restrict the devices to
(via dma_mask and dma_mask_coherent) to 31 bit, which is sub-optimal.
Thus s390 we would benefit form having control over what flags are
dropped.
Signed-off-by: H
ice *dev)
> > {
> > - return sev_active();
> > + return is_prot_virt_guest();
> > }
>
> Do we want to keep the comment for force_dma_unencrypted?
Yes we do. With the comment transferred:
Reviewed-by: Halil Pasic
>
> Otherwise looks good:
>
> Reviewed-by: Christoph Hellwig
On Fri, 12 Jul 2019 18:55:47 -0300
Thiago Jung Bauermann wrote:
>
> [ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]
>
> Hello Halil,
>
> Thanks for the quick review.
>
> Halil Pasic writes:
>
> > On Fri, 12 Jul 2019 02:36:31
On Fri, 12 Jul 2019 17:11:29 +0200
Christoph Hellwig wrote:
> On Fri, Jul 12, 2019 at 04:51:53PM +0200, Halil Pasic wrote:
> > Thank you very much! I will have another look, but it seems to me,
> > without further measures taken, this would break protected virtualization
> >
On Fri, 12 Jul 2019 16:08:12 +0200
Christoph Hellwig wrote:
> On Fri, Jul 12, 2019 at 03:09:12PM +0200, Halil Pasic wrote:
> > This is the implementation for the guys that don't
> > have ARCH_HAS_MEM_ENCRYPT.
> >
> > Means sev_active() may not be used in such
On Fri, 12 Jul 2019 02:36:31 -0300
Thiago Jung Bauermann wrote:
> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
> appear in generic kernel code because it forces non-x86 architectures to
> define the sev_active() function, which doesn't make a lot of sense.
sev_acti
50 matches
Mail list logo
