Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

25 participants
6309 discussions

The experience that left me skeptical about love

by claudiamephins＠gmail.com

Love is not as easy as people make it look like and in love commitment is key, commitment reveals who is true and who is not, I fell in love with the wrong one who was not committed, who did not to sacrifice for what we had, I was lied to and played on, I was seeing the signs but was not sure what it was until my sister told me about Mac and his team (macprivateinvestigators @ gmail .com) who helped expose my husband and all his secrets on how he was involved with other women, the evidence provided made the divorce case easy for me, now I feel free.

2 weeks, 6 days

The experience that left me skeptical about love

by claudiamephins＠gmail.com

2 weeks, 6 days

corgi puppies for sale near me

by Tirrell Otalvaro

2 weeks, 6 days

corgis for sale

by Tirrell Otalvaro

2 weeks, 6 days

corgi puppies

by Tirrell Otalvaro

2 weeks, 6 days

corgi puppies for sale

by Tirrell Otalvaro

2 weeks, 6 days

Re: [PATCH v4 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory

by Jason Gunthorpe

On Tue, Mar 17, 2026 at 09:26:21AM +0100, Jiri Pirko wrote: > >...although, why *shouldn't* this be allowed with a vIOMMU? (Especially given > >that a vIOMMU for untrusted devices can be emulated by the host VMM without > >the CoCo hypervisor having to care at all - again, at least on Arm and other > >architectures where IOMMUs are regular driver model devices) > > Well, when iommu path is able to consume the attr, this restriction > should be lifted. This is basically a sanity check for the > dma_map_phys() caller. Right we eventually need a matching IOMMU_DECRYPTED. It needs to mirror how the CPUs work - any place that would use pgprot_decrypted to create a PTE should use IOMMU_PROT_DECRYPTED to create an iommu mapping. The current hack in AMD assumes IOMMU_DECRYPTED behavior for IOMMU_MMIO, but that isn't general enough.. There is some maze to get there but for the moment I think it is fine to just not support vIOMMU, it isn't like any vIOMMU drivers even exist for CC VMs right now. Jason

2 weeks, 6 days

Re: [PATCH net-next v3 0/2] dma-buf: heaps: system: add an option to allocate explicitly decrypted memory

by Jason Gunthorpe

On Tue, Mar 24, 2026 at 05:36:23PM +0000, Mostafa Saleh wrote: > But it's not about drivers in that case, it's about many places > (SWIOTLB and DMA-direct) calling set_memory_decrypted() without clear > ownership so in some cases they step on each other's toes, and I don't > think that will get simpler with yet another caller in this series I don't understand how this can be, ownership is clear. SWIOTLB owns the buffer, dma alloc coherent owns the buffer, user owns the buffer. There should be no other cases, and they don't step on each other unless the APIs are being used wrong. > I am fine with the API design you mentioned, but I believe that it > needs clear documentation specifying who is responsible for > decryption. The code should provide wrappers checking for these cases > instead of having is_swiotlb_for_alloc() and force_dma_unencrypted() > everywhere in DMA-direct. Redoingt how dma-api works internally is some other project... It would be nice if swiotlb would sort of recursively DMA map using the new flag instead of open coding it but that is pretty minor. Jason

2 weeks, 6 days

Re: [PATCH net-next v3 0/2] dma-buf: heaps: system: add an option to allocate explicitly decrypted memory

by Jason Gunthorpe

On Tue, Mar 24, 2026 at 12:14:36PM +0000, Mostafa Saleh wrote: > On Tue, Mar 24, 2026 at 12:01 PM Jason Gunthorpe <jgg(a)ziepe.ca> wrote: > > > > On Tue, Mar 17, 2026 at 01:24:13PM +0000, Mostafa Saleh wrote: > > > > > On the other hand, for restricted-dma, the memory decryption is deep > > > in the DMA direct memory allocation and the DMA API callers (for ex > > > virtio drivers) are clueless about it and can’t pass any attrs. > > > My proposal was specific to restricted-dma and won’t work for your case. > > > > How is this any different from CC? > > > > If the device cannot dma to "encrypted" memory, whatever that means > > for you, then the DMA API: > > - Makes dma alloc coherent return "decrypted" memory, and the built > > in mapping of coherent memory knows about this > > - Makes dma_map_xxx use SWIOTLB to bounce to decrypted memory > > > > There is no need for something like virtio drivers to be aware of > > any of this. > > > > On the other hand if the driver deliberately allocates decrypted > > memory without using DMA API alloc coherent then it knows it did it > > and can pass the flag to map it. > > > > The problem is that the DMA API currently gets confused by this; it > can end up double decrypting the memory or using the wrong functions > as mentioned in [1] I fully belive there are bugs, but the API design is sound. If you use the coherent allocations from the DMA API then it knows decryption has happened when it generates a dma_addr_t and there should be no issue. Now, if drivers are using the DMA API wrong, like trying to double map coherent allocations then they are broken. I also would not be surprised to find cases like this. Jason

3 weeks

Re: [PATCH net-next v3 0/2] dma-buf: heaps: system: add an option to allocate explicitly decrypted memory

by Jason Gunthorpe

On Tue, Mar 17, 2026 at 01:24:13PM +0000, Mostafa Saleh wrote: > On the other hand, for restricted-dma, the memory decryption is deep > in the DMA direct memory allocation and the DMA API callers (for ex > virtio drivers) are clueless about it and can’t pass any attrs. > My proposal was specific to restricted-dma and won’t work for your case. How is this any different from CC? If the device cannot dma to "encrypted" memory, whatever that means for you, then the DMA API: - Makes dma alloc coherent return "decrypted" memory, and the built in mapping of coherent memory knows about this - Makes dma_map_xxx use SWIOTLB to bounce to decrypted memory There is no need for something like virtio drivers to be aware of any of this. On the other hand if the driver deliberately allocates decrypted memory without using DMA API alloc coherent then it knows it did it and can pass the flag to map it. > I am wondering if the kernel should have a more solid, unified method > for identifying already-decrypted memory instead. Perhaps we need a > way for the DMA API to natively recognize the encryption state of a > physical page (working alongside force_dma_unencrypted(dev)), rather > than relying on caller-provided attributes? Definately not, we do not want the DMA API inspecting things like this. Jason

3 weeks

← Newer
1
...
8
9
10
11
12
13
14
...
631
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig