Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

69 participants
6233 discussions

by luckaswilli7＠gmail.com

Buy real and fake Passports (WhatsApp: +1 (615)-314-6286) renew passports online, apply for legal passports, buy fake passports, Buy US passports, buy Chinese passports, buy Canadian passports (Telegram: @Globaldocs26) buy passports and visa, buy passports, buy passport citizenship, visas and passports passport and visa are same, passport and visa apply, is passports and visas a legit website, difference between passports and visas do i need a visa with my passport, how to apply for passport and passport card, is passports and visas legit Buy counterfeit currency. Buy US dollars (USD), Chinese yuan (RMB), buy Canadian dollars (CAD), Chinese yuan (CNY), Hong Kong dollars (HKD), Malaysian ringgit (MYR), Australian dollars (AUD), buy euros (EUR) (WhatsApp：+1(615)-314-6286). Buy high-quality, indistinguishable counterfeit banknotes. We only offer high-quality counterfeit currency. We provide perfectly replicated counterfeit banknotes with holograms and all available security features. Indistinguishable to the naked eye and touch. 100% indistinguishable counterfeit banknotes, printed on 80% cotton and 20% cellulose paper. Buy a US student visa, buy TCF, TEF, TOEFL, IELTS, TOEIC test scores (Email: guanyuguohai(a)gmail.com), buy Canadian citizenship, buy US citizenship, buy Canadian TCF, TEF, CELPIP, CELTA certificates, how to immigrate to Canada? Buy a driver’s license, ID card, US green card (Telegram：@Buylegitpassports1), Social Security Number (SSN), work permit, new ID card, National Insurance Card, NIN, SIN, marriage certificate, birth certificate Want to start a new chapter in your life with a new identity? Protect your privacy, build a new credit history, bypass criminal record checks, and regain your freedom? Apply for a new identity now! (WhatsApp：+1(615)-314-6286). You can contact us using the following details WhatsApp: +1 (615)-314-6286 Telegram: @Globaldocs26 Email: Karlvonlinne74(a)gmail.com Website: https://flypassports.com/ Website: https://buylegitpassports.com/ Telegram: https://t.me/globaldocs2 buy passports and visa, buy passport canada, passports that can be bought, buy visa gift card with paypal canada, buy canadian passport, passport and visa are same, passport and visa apply, is passports and visas a legit website, difference between passports and visas, do i need a visa with my passport, how to apply for passport and passport card, passports visa and more, can you buy an american passport, buy a pasport, buying american passport, buy a paasport, buyable passports, pbuy passport, passport and visa check, passport and visa card, passports and visas coupon code, can i transfer canada visa to new passport, passports and visas.com legit, can you buy a canadian passport, passport and visa difference, passport and visa difference in hindi, passport and visa department of ra, passport and visa difference in marathi, passports and visas denver, passport and visa documents, passport and visa dubai, list of passports by visa free passport and visa express, passport and visa emirates, passport and visa express reviews, buy visa e gift card canada, buy passports online, can you buy a visa online, passport and visa free countries for india, passport and visa free countries, passport and visa for uk, buy passports, buy american passport, passport and visa holder, passport and visa how much, difference between passport and passport card ireland, buy passports and citizenship, passport and visa id photo maker, passport and visa is the same, passport and visa index, passports i can buy, passport and visa jobs, passports to buy, passports you can buy, buying passports, passport and visa kenya, how to get passport card if i already have passport, what passport can i buy, passports and visas llc, passport and visa link, passports and visas legit, passport and visa logo, passport to buy, passport and visa meaning, passport and visa manual 2006 pdf, passport and visa me antar, passport and visa mein kya antar hai, passport and visa me difference in hindi, passport and visa me difference, passport and visa mein antar, passport and visa me antar in hindi, can i transfer my visa to a new, passport, buy your passport, passport and visa name different, passport and visa number, how to buy a new passport, do i need to transfer visa to new passport, passport and visa office, passport and visa org, passport and visa on emirates, passport and visa photo photogov, passport and visa price, passport and visa photo, passport and visa price in india, passport and visa photo size, passport and visa photo requirements, passport and visa photo studio near me, passport and visa page, passport and visa qatar airways, passport and visa quartus global services, passport and visa quartus global services missouri city, passport and visa questions, is expedited passports and visas legit, buy quebec passport. passport and visa requirements, passports and visas reviews, passport and visa requirements for thailand, passport and visa renewal passport and visa requirements for spain, passport and visa requirements for dubai, passport and visa requirements for italy, passport and visa requirements for uk, passport and visa requirements for singapore, passport and visa requirements for australia, buying passport other country passport and visa services, passport and visa services near me, passport and visa solutions, passport and visa same, passport and visa status passport and visa services chicago, passport and visa stamp, are visas and passports the same thing, passport and visa the same passport and visa the same thing, passports and visas unlimited, passport and visa uk, us passport visa, passport and visa what is the difference buy a second passport, passport that you can buy, buy an american passport, buy a passport, how much to buy a canadian passport https://flypassports.com/service-category/passport/ https://flypassports.com/service/germany-driving-licence/# https://flypassports.com/services/ https://flypassports.com/faq/ https://flypassports.com/about-us/ https://flypassports.com/contact-us/ https://flypassports.com/service/canadian-passport/ https://flypassports.com/service/bulgarian-drivers-license/ https://flypassports.com/service/chinese-passport-renewal/ https://flypassports.com/service/illinois-drivers-license/ https://flypassports.com/service/usa-passport/ https://flypassports.com/service/austrian-drivers-license/ https://flypassports.com/service/netherlands-passport-application/ https://flypassports.com/service/vermont-drivers-license/ https://flypassports.com/service/korean-passport-renewal/ https://flypassports.com/service/germany-driving-licence/ https://buylegitpassports.com/ https://buylegitpassports.com/apply/ https://buylegitpassports.com/buy-fake-diploma/ https://buylegitpassports.com/social-security-card-generator/ https://buylegitpassports.com/how-do-we-get-a-passport/ https://buylegitpassports.com/real-and-fake-passport/ https://buylegitpassports.com/buy-fake-chinese-passport/ https://buylegitpassports.com/buy-canadian-passport-online/ https://buylegitpassports.com/croatia-driven-license/ https://buylegitpassports.com/buy-brazil-driver-license/ https://buylegitpassports.com/buy-hungary-driver-license/ https://buylegitpassports.com/buy-fake-social-security-number-card/ https://buylegitpassports.com/how-can-i-get-california-drivers-license/ WhatsApp number: +1 (615)-314-6286 Telegram: @Globaldocs26 Email: Karlvonlinne74(a)gmail.com Website: https://flypassports.com/ Website: https://buylegitpassports.com/ Telegram: https://t.me/globaldocs2

1 week, 4 days

Shred Some Slopes: Getting the Hang of Snow Rider 3D

by careful.earthworm.usil＠hidingmail.com

Feeling the need for speed and a bit of winter fun, even when the weather outside is frightful? Then maybe it’s time to check out Snow Rider 3D. This simple but surprisingly addictive game offers a thrill of downhill skiing and snowboarding right from your browser, no downloads required. Let’s break down how to jump in and start enjoying this surprisingly engaging title. https://snowriderfree.com/ Gameplay: Simple Controls, Endless Possibilities The core gameplay of Snow Rider 3D is deceptively straightforward. You control your character's direction using the left and right arrow keys (or A and D). Your objective? Navigate through a series of procedurally generated slopes littered with obstacles. These obstacles range from simple ramps and rails to more challenging hazards like trees, snowdrifts, and even abandoned shacks. The beauty of Snow Rider 3D lies in its physics. While simple, they feel surprisingly realistic. You'll need to anticipate turns, adjust your speed, and time your jumps to successfully navigate the terrain. A crash will reset you to the beginning of the course, so precision and patience are key. The game offers different levels, each presenting a unique challenge. Some focus on speed and long jumps, while others demand skillful maneuvering through tight spaces. As you progress, you unlock new skins and sleds, adding a touch of customization to your experience. Think of it as a casual time-killer that can quickly turn into an hour-long obsession! Tips for Mastering the Mountain: Alright, so you're ready to hit the slopes. Here are a few tips to help you improve your runs and avoid those frustrating wipeouts: Practice Makes Perfect: Don't get discouraged by early crashes. The more you play, the better you'll understand the physics and learn to anticipate the terrain. Master the Turns: Smooth, controlled turns are essential for maintaining speed and avoiding obstacles. Practice feathering the arrow keys to make subtle adjustments. Timing is Everything: When approaching jumps and ramps, pay close attention to your speed and angle. A well-timed jump can make all the difference. Don't Be Afraid to Slow Down: Sometimes, the fastest route isn't the safest. Don't be afraid to ease off the gas and navigate tricky sections with caution. Consider looking up guides for specific levels of Snow Rider 3D at websites like Snow Rider 3D if you’re really struggling. Experiment with Sleds and Skins: Different sleds may offer slight variations in handling. Try out different options to find one that suits your playstyle. Conclusion: A Fun and Accessible Winter Escape Snow Rider 3D is a surprisingly addictive and accessible game that’s perfect for a quick dose of winter fun. It's simple controls and challenging gameplay make it easy to pick up and play, while its procedural generation ensures that each run is a unique experience. So, whether you're looking for a casual time-killer or a challenging skill-based game, Snow Rider 3D is definitely worth checking out.

1 week, 4 days

[PATCH v9 0/7] Rust bindings for gem shmem

by Lyude Paul

This is the next version of the shmem backed GEM objects series originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/156093/ This patch series may be applied on top of the driver-core/driver-core-testing branch: https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git… Changelogs are per-patch Asahi Lina (2): rust: helpers: Add bindings/wrappers for dma_resv_lock rust: drm: gem: shmem: Add DRM shmem helper abstraction Lyude Paul (5): rust: drm: Add gem::impl_aref_for_gem_obj! rust: drm: gem: Add raw_dma_resv() function rust: gem: Introduce DriverObject::Args rust: drm: gem: Introduce shmem::SGTable rust: drm/gem: Add vmap functions to shmem bindings drivers/gpu/drm/nova/gem.rs | 5 +- drivers/gpu/drm/tyr/gem.rs | 3 +- rust/bindings/bindings_helper.h | 3 + rust/helpers/dma-resv.c | 13 + rust/helpers/drm.c | 56 ++- rust/helpers/helpers.c | 1 + rust/kernel/drm/gem/mod.rs | 79 +++- rust/kernel/drm/gem/shmem.rs | 654 ++++++++++++++++++++++++++++++++ 8 files changed, 792 insertions(+), 22 deletions(-) create mode 100644 rust/helpers/dma-resv.c create mode 100644 rust/kernel/drm/gem/shmem.rs base-commit: dc33ae50d32b509af5ae61030912fa20c79ef112 prerequisite-patch-id: c631986f96e2073263e97e82a65b96fc5ada6924 prerequisite-patch-id: ae853e8eb8d58c77881371960be4ae92755e83c6 prerequisite-patch-id: 0ab78b50648c7d8f66b83c32ed2af0ec3ede42a3 prerequisite-patch-id: 636ec7f913f4047e5e1a1788f3e835b7259698c2 prerequisite-patch-id: d75e4d7140eadeeed8017af8cd093bfd2766ee8e prerequisite-patch-id: 67a8010c1bc95bca1d2cf6b246c67bc79d24e766 -- 2.53.0

1 week, 4 days

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

by Robin Murphy

On 2026-03-16 12:58 pm, Jiri Pirko wrote: > From: Jiri Pirko <jiri(a)nvidia.com> > > Current CC designs don't place a vIOMMU in front of untrusted devices. > Instead, the DMA API forces all untrusted device DMA through swiotlb > bounce buffers (is_swiotlb_force_bounce()) which copies data into > decrypted memory on behalf of the device. > > When a caller has already arranged for the memory to be decrypted > via set_memory_decrypted(), the DMA API needs to know so it can map > directly using the unencrypted physical address rather than bounce > buffering. Following the pattern of DMA_ATTR_MMIO, add > DMA_ATTR_CC_DECRYPTED for this purpose. Like the MMIO case, only the > caller knows what kind of memory it has and must inform the DMA API > for it to work correctly. Echoing Jason's point, if the intent of this is to indicate shared memory, please call it DMA_ATTR_CC_SHARED. Yes, some of the existing APIs are badly named because they conflated intent with implementation details; that is no reason to keep wilfully making the same mistake. At least with Arm CCA, the architecture enforces *confidentiality* pretty much orthogonally to encryption - if your threat model excludes physical attacks against DRAM, you can still have Realms isolated from each other (and of course other execution states) without even implementing the memory encryption feature; conversely if you do have it, then even all the shared/host memory may still be physically encrypted, it just has its own context (key) distinct from the Realm ones. Similarly, while it's not a "true" CoCo environment, pKVM has a similar notion of shared vs. private which can benefit from piggy-backing off much of the CoCo infrastructure in places like the DMA layer, but has nothing whatsoever to do with actual encryption. Furthermore, "shared" is just shorter and more readable, even before I invoke the previous discussion of why it should be "unencrypted" rather than "decrypted" anyway ;) > Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> > --- > v3->v4: > - added some sanity checks to dma_map_phys and dma_unmap_phys > - enhanced documentation of DMA_ATTR_CC_DECRYPTED attr > v1->v2: > - rebased on top of recent dma-mapping-fixes > --- > include/linux/dma-mapping.h | 10 ++++++++++ > include/trace/events/dma.h | 3 ++- > kernel/dma/direct.h | 14 +++++++++++--- > kernel/dma/mapping.c | 13 +++++++++++-- > 4 files changed, 34 insertions(+), 6 deletions(-) > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index 29973baa0581..476964d2b22f 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -85,6 +85,16 @@ > * a cacheline must have this attribute for this to be considered safe. > */ > #define DMA_ATTR_CPU_CACHE_CLEAN (1UL << 11) > +/* > + * DMA_ATTR_CC_DECRYPTED: Indicates the DMA mapping is decrypted (shared) for > + * confidential computing guests. For normal system memory the caller must have > + * called set_memory_decrypted(), and pgprot_decrypted must be used when > + * creating CPU PTEs for the mapping. The same decrypted semantic may be passed > + * to the vIOMMU when it sets up the IOPTE. For MMIO use together with That being "the vIOMMU" that you said doesn't exist, and which is explicitly not supported?... > + * DMA_ATTR_MMIO to indicate decrypted MMIO. Unless DMA_ATTR_MMIO is provided > + * a struct page is required. > + */ > +#define DMA_ATTR_CC_DECRYPTED (1UL << 12) > > /* > * A dma_addr_t can hold any valid DMA or bus address for the platform. It can > diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h > index 33e99e792f1a..b8082d5177c4 100644 > --- a/include/trace/events/dma.h > +++ b/include/trace/events/dma.h > @@ -32,7 +32,8 @@ TRACE_DEFINE_ENUM(DMA_NONE); > { DMA_ATTR_ALLOC_SINGLE_PAGES, "ALLOC_SINGLE_PAGES" }, \ > { DMA_ATTR_NO_WARN, "NO_WARN" }, \ > { DMA_ATTR_PRIVILEGED, "PRIVILEGED" }, \ > - { DMA_ATTR_MMIO, "MMIO" }) > + { DMA_ATTR_MMIO, "MMIO" }, \ > + { DMA_ATTR_CC_DECRYPTED, "CC_DECRYPTED" }) > > DECLARE_EVENT_CLASS(dma_map, > TP_PROTO(struct device *dev, phys_addr_t phys_addr, dma_addr_t dma_addr, > diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h > index e89f175e9c2d..c047a9d0fda3 100644 > --- a/kernel/dma/direct.h > +++ b/kernel/dma/direct.h > @@ -84,16 +84,24 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev, > dma_addr_t dma_addr; > > if (is_swiotlb_force_bounce(dev)) { > - if (attrs & DMA_ATTR_MMIO) > - return DMA_MAPPING_ERROR; > + if (!(attrs & DMA_ATTR_CC_DECRYPTED)) { > + if (attrs & DMA_ATTR_MMIO) > + return DMA_MAPPING_ERROR; > > - return swiotlb_map(dev, phys, size, dir, attrs); > + return swiotlb_map(dev, phys, size, dir, attrs); > + } > + } else if (attrs & DMA_ATTR_CC_DECRYPTED) { > + return DMA_MAPPING_ERROR; > } > > if (attrs & DMA_ATTR_MMIO) { > dma_addr = phys; > if (unlikely(!dma_capable(dev, dma_addr, size, false))) > goto err_overflow; > + } else if (attrs & DMA_ATTR_CC_DECRYPTED) { > + dma_addr = phys_to_dma_unencrypted(dev, phys); > + if (unlikely(!dma_capable(dev, dma_addr, size, false))) > + goto err_overflow; > } else { > dma_addr = phys_to_dma(dev, phys); > if (unlikely(!dma_capable(dev, dma_addr, size, true)) || > diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c > index 3928a509c44c..abb0c88b188b 100644 > --- a/kernel/dma/mapping.c > +++ b/kernel/dma/mapping.c > @@ -157,6 +157,7 @@ dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, > { > const struct dma_map_ops *ops = get_dma_ops(dev); > bool is_mmio = attrs & DMA_ATTR_MMIO; > + bool is_cc_decrypted = attrs & DMA_ATTR_CC_DECRYPTED; > dma_addr_t addr = DMA_MAPPING_ERROR; > > BUG_ON(!valid_dma_direction(dir)); > @@ -165,8 +166,11 @@ dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, > return DMA_MAPPING_ERROR; > > if (dma_map_direct(dev, ops) || > - (!is_mmio && arch_dma_map_phys_direct(dev, phys + size))) > + (!is_mmio && !is_cc_decrypted && > + arch_dma_map_phys_direct(dev, phys + size))) > addr = dma_direct_map_phys(dev, phys, size, dir, attrs); > + else if (is_cc_decrypted) > + return DMA_MAPPING_ERROR; > else if (use_dma_iommu(dev)) ...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) > addr = iommu_dma_map_phys(dev, phys, size, dir, attrs); > else if (ops->map_phys) Or indeed any other non-direct ops? Obviously all the legacy architectures like Alpha are never going to see this or care, but I could imagine Xen and possibly PowerPC might. Thanks, Robin. > @@ -203,11 +207,16 @@ void dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size, > { > const struct dma_map_ops *ops = get_dma_ops(dev); > bool is_mmio = attrs & DMA_ATTR_MMIO; > + bool is_cc_decrypted = attrs & DMA_ATTR_CC_DECRYPTED; > > BUG_ON(!valid_dma_direction(dir)); > + > if (dma_map_direct(dev, ops) || > - (!is_mmio && arch_dma_unmap_phys_direct(dev, addr + size))) > + (!is_mmio && !is_cc_decrypted && > + arch_dma_unmap_phys_direct(dev, addr + size))) > dma_direct_unmap_phys(dev, addr, size, dir, attrs); > + else if (is_cc_decrypted) > + return; > else if (use_dma_iommu(dev)) > iommu_dma_unmap_phys(dev, addr, size, dir, attrs); > else if (ops->unmap_phys)

1 week, 4 days

TRUSTED EXPERTS ONLINE RECOVERY SOLUTIONS//ALMIGHTY RECOVERY COIN

by Jeremy Thorgan

Almighty Cryptocurrency Recovery is a private investigation, asset recovery, and financial regulator. We specialize in instances involving recovery scams, cryptocurrency, fake investment schemes, and ethical hacking. We examine the factors influencing your score and are also experts in credit repair. removing criminal records, school grades, and jobs involving phone and social media hacking. Every piece of software required to carry out recoveries from beginning to end is available. The writers and offenders band together to establish a syndicate, so be wary of false reviews and testimonials on the internet.To get started, send an email to our support team at the address below as soon as you can. almightyrecoverycoin(a)mail.com and whatsapp +53 51 55 6969 Visit website; almightyrecoveryco.wixsite.com/almighty-recovery-co Stay Safe!

1 week, 5 days

5
4
10 0

[PATCH v3 0/6] dma-buf: heaps: add coherent reserved-memory heap

by Albert Esteve

This patch series adds a new dma-buf heap driver that exposes coherent, non‑reusable reserved-memory regions as named heaps, so userspace can explicitly allocate buffers from those device‑specific pools. Motivation: we want cgroup accounting for all userspace‑visible buffer allocations (DRM, v4l2, dma‑buf heaps, etc.). That’s hard to do when drivers call dma_alloc_attrs() directly because the accounting controller (memcg vs dmem) is ambiguous. The long‑term plan is to steer those paths toward dma‑buf heaps, where each heap can unambiguously charge a single controller. To reach that goal, we need a heap backend for each dma_alloc_attrs() memory type. CMA and system heaps already exist; coherent reserved‑memory was the missing piece, since many SoCs define dedicated, device‑local coherent pools in DT under /reserved-memory using "shared-dma-pool" with non‑reusable regions (i.e., not CMA) that are carved out exclusively for coherent DMA and are currently only usable by in‑kernel drivers. Because these regions are device‑dependent, each heap instance binds a heap device to its reserved‑mem region via a newly introduced helper function -namely, of_reserved_mem_device_init_with_mem()- so coherent allocations use the correct dev->dma_mem. Charging to cgroups for these buffers is intentionally left out to keep review focused on the new heap; I plan to follow up based on Eric’s [1] and Maxime’s [2] work on dmem charging from userspace. This series also makes the new heap driver modular, in line with the CMA heap change in [3]. [1] https://lore.kernel.org/all/20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2… [2] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… [3] https://lore.kernel.org/all/20260303-dma-buf-heaps-as-modules-v3-0-24344812… Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Changes in v3: - Reorganized changesets among patches to ensure bisectability - Removed unused dma_heap_coherent_register() leftover - Removed fallback when setting mask in coherent heap dev, since dma_set_mask() already truncates to supported masks - Moved struct rmem_assigned_device (rd) logic to of_reserved_mem_device_init_with_mem() to allow listing the device - Link to v2: https://lore.kernel.org/r/20260303-b4-dmabuf-heap-coherent-rmem-v2-0-65a465… Changes in v2: - Removed dmem charging parts - Moved coherent heap registering logic to coherent.c - Made heap device a member of struct dma_heap - Split dma_heap_add logic into create/register, to be able to access the stored heap device before registered. - Avoid platform device in favour of heap device - Added a wrapper to rmem device_init() op - Switched from late_initcall() to module_init() - Made the coherent heap driver modular - Link to v1: https://lore.kernel.org/r/20260224-b4-dmabuf-heap-coherent-rmem-v1-1-dffef4… --- Albert Esteve (5): dma-buf: dma-heap: split dma_heap_add of_reserved_mem: add a helper for rmem device_init op dma: coherent: store reserved memory coherent regions dma-buf: heaps: Add Coherent heap to dmabuf heaps dma-buf: heaps: coherent: Turn heap into a module John Stultz (1): dma-buf: dma-heap: Keep track of the heap device struct drivers/dma-buf/dma-heap.c | 138 +++++++++-- drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/coherent_heap.c | 417 ++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 68 ++++-- include/linux/dma-heap.h | 5 + include/linux/dma-map-ops.h | 7 + include/linux/of_reserved_mem.h | 8 + kernel/dma/coherent.c | 34 +++ 9 files changed, 640 insertions(+), 47 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

1 week, 5 days

Are your l0st bitc0ins gone forever? Here’s how you might be able to rec0ver them

by Ambrose MacQuoid

Many of us have f@ll€n for inves tment, pon zi, love, dating, even cryp to sc@m, it's really sad, few months ago I was a vict im of an invest ment sc@m , but today I got my fuπds back to my wall et , unbelievable right? I'll tell you h0w: Firstly, Believe in ghosttrackha ckers these guys are geπuine and geπius, I stumbled upon series of reviews from th€m, after months of l00sing my $20k worth of bitc0iπ thinking they were gone forever I sent them a m@il, €xplaining what happened and if there was any possibility, they said "nothing w€ can't haπdle" I sat back and in 48hrs they ask€d for my addr€ss and they r€c0v€r€d the full funds. I couldn't believe my eyes, I told them I'll go spr€ad the words to many others who have fall€n vi¢t|m. Goodluck ghosttrackhackers@ gmail . com

2 weeks

[PATCH] udmabuf: Do not create malformed scatterlists

by Jason Gunthorpe

Using a sg_set_folio() loop for every 4K results in a malformed scatterlist because sg_set_folio() has an issue with offsets > PAGE_SIZE and because scatterlist expects the creator to build a list which consolidates any physical contiguity. sg_alloc_table_from_pages() creates a valid scatterlist directly from a struct page array, so go back to that. Remove the offsets allocation and just store an array of tail pages as it did before the below commit. Everything wants that anyhow. Fixes: 0c8b91ef5100 ("udmabuf: add back support for mapping hugetlb pages") Reported-by: Julian Orth <ju.orth(a)gmail.com> Closes: https://lore.kernel.org/all/20260308-scatterlist-v1-1-39c4566b0bba@gmail.co… Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> --- drivers/dma-buf/udmabuf.c | 49 +++++++++++---------------------------- 1 file changed, 13 insertions(+), 36 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 94b8ecb892bb17..5d687860445137 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -26,10 +26,10 @@ MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in megabytes. Default is struct udmabuf { pgoff_t pagecount; - struct folio **folios; + struct page **pages; /** - * Unlike folios, pinned_folios is only used for unpin. + * Unlike pages, pinned_folios is only used for unpin. * So, nr_pinned is not the same to pagecount, the pinned_folios * only set each folio which already pinned when udmabuf_create. * Note that, since a folio may be pinned multiple times, each folio @@ -41,7 +41,6 @@ struct udmabuf { struct sg_table *sg; struct miscdevice *device; - pgoff_t *offsets; }; static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) @@ -55,8 +54,7 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) if (pgoff >= ubuf->pagecount) return VM_FAULT_SIGBUS; - pfn = folio_pfn(ubuf->folios[pgoff]); - pfn += ubuf->offsets[pgoff] >> PAGE_SHIFT; + pfn = page_to_pfn(ubuf->pages[pgoff]); ret = vmf_insert_pfn(vma, vmf->address, pfn); if (ret & VM_FAULT_ERROR) @@ -73,8 +71,7 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) if (WARN_ON(pgoff >= ubuf->pagecount)) break; - pfn = folio_pfn(ubuf->folios[pgoff]); - pfn += ubuf->offsets[pgoff] >> PAGE_SHIFT; + pfn = page_to_pfn(ubuf->pages[pgoff]); /** * If the below vmf_insert_pfn() fails, we do not return an @@ -109,22 +106,11 @@ static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) static int vmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) { struct udmabuf *ubuf = buf->priv; - struct page **pages; void *vaddr; - pgoff_t pg; dma_resv_assert_held(buf->resv); - pages = kvmalloc_objs(*pages, ubuf->pagecount); - if (!pages) - return -ENOMEM; - - for (pg = 0; pg < ubuf->pagecount; pg++) - pages[pg] = folio_page(ubuf->folios[pg], - ubuf->offsets[pg] >> PAGE_SHIFT); - - vaddr = vm_map_ram(pages, ubuf->pagecount, -1); - kvfree(pages); + vaddr = vm_map_ram(ubuf->pages, ubuf->pagecount, -1); if (!vaddr) return -EINVAL; @@ -146,22 +132,18 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, { struct udmabuf *ubuf = buf->priv; struct sg_table *sg; - struct scatterlist *sgl; - unsigned int i = 0; int ret; sg = kzalloc_obj(*sg); if (!sg) return ERR_PTR(-ENOMEM); - ret = sg_alloc_table(sg, ubuf->pagecount, GFP_KERNEL); + ret = sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount, 0, + ubuf->pagecount << PAGE_SHIFT, + GFP_KERNEL); if (ret < 0) goto err_alloc; - for_each_sg(sg->sgl, sgl, ubuf->pagecount, i) - sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, - ubuf->offsets[i]); - ret = dma_map_sgtable(dev, sg, direction, 0); if (ret < 0) goto err_map; @@ -207,12 +189,8 @@ static void unpin_all_folios(struct udmabuf *ubuf) static __always_inline int init_udmabuf(struct udmabuf *ubuf, pgoff_t pgcnt) { - ubuf->folios = kvmalloc_objs(*ubuf->folios, pgcnt); - if (!ubuf->folios) - return -ENOMEM; - - ubuf->offsets = kvzalloc_objs(*ubuf->offsets, pgcnt); - if (!ubuf->offsets) + ubuf->pages = kvmalloc_objs(*ubuf->pages, pgcnt); + if (!ubuf->pages) return -ENOMEM; ubuf->pinned_folios = kvmalloc_objs(*ubuf->pinned_folios, pgcnt); @@ -225,8 +203,7 @@ static __always_inline int init_udmabuf(struct udmabuf *ubuf, pgoff_t pgcnt) static __always_inline void deinit_udmabuf(struct udmabuf *ubuf) { unpin_all_folios(ubuf); - kvfree(ubuf->offsets); - kvfree(ubuf->folios); + kvfree(ubuf->pages); } static void release_udmabuf(struct dma_buf *buf) @@ -344,8 +321,8 @@ static long udmabuf_pin_folios(struct udmabuf *ubuf, struct file *memfd, ubuf->pinned_folios[nr_pinned++] = folios[cur_folio]; for (; subpgoff < fsize; subpgoff += PAGE_SIZE) { - ubuf->folios[upgcnt] = folios[cur_folio]; - ubuf->offsets[upgcnt] = subpgoff; + ubuf->pages[upgcnt] = folio_page(folios[cur_folio], + subpgoff >> PAGE_SHIFT); ++upgcnt; if (++cur_pgcnt >= pgcnt) base-commit: 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681 -- 2.43.0

2 weeks

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

by Leon Romanovsky

On Thu, Mar 05, 2026 at 01:36:40PM +0100, Jiri Pirko wrote: > From: Jiri Pirko <jiri(a)nvidia.com> > > Current CC designs don't place a vIOMMU in front of untrusted devices. > Instead, the DMA API forces all untrusted device DMA through swiotlb > bounce buffers (is_swiotlb_force_bounce()) which copies data into > decrypted memory on behalf of the device. > > When a caller has already arranged for the memory to be decrypted > via set_memory_decrypted(), the DMA API needs to know so it can map > directly using the unencrypted physical address rather than bounce > buffering. Following the pattern of DMA_ATTR_MMIO, add > DMA_ATTR_CC_DECRYPTED for this purpose. Like the MMIO case, only the > caller knows what kind of memory it has and must inform the DMA API > for it to work correctly. > > Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> > --- > v1->v2: > - rebased on top of recent dma-mapping-fixes > --- > include/linux/dma-mapping.h | 6 ++++++ > include/trace/events/dma.h | 3 ++- > kernel/dma/direct.h | 14 +++++++++++--- > 3 files changed, 19 insertions(+), 4 deletions(-) > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index 29973baa0581..ae3d85e494ec 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -85,6 +85,12 @@ > * a cacheline must have this attribute for this to be considered safe. > */ > #define DMA_ATTR_CPU_CACHE_CLEAN (1UL << 11) > +/* > + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted > + * (shared) for confidential computing guests. The caller must have > + * called set_memory_decrypted(). A struct page is required. > + */ > +#define DMA_ATTR_CC_DECRYPTED (1UL << 12) While adding the new attribute is fine, I would expect additional checks in dma_map_phys() to ensure the attribute cannot be misused. For example, WARN_ON(attrs & (DMA_ATTR_CC_DECRYPTED | DMA_ATTR_MMIO)), along with a check that we are taking the direct path only. Thanks

2 weeks, 1 day

Re: [RFC v2 PATCH 00/10] vfio/pci: Add mmap() for DMABUFs

by Christian König

On 3/12/26 19:45, Matt Evans wrote: > Hi all, > > > There were various suggestions in the September 2025 thread "[TECH > TOPIC] vfio, iommufd: Enabling user space drivers to vend more > granular access to client processes" [0], and LPC discussions, around > improving the situation for multi-process userspace driver designs. > This RFC series implements some of these ideas. > > (Thanks for feedback on v1! Revised series, with changes noted > inline.) > > Background: Multi-process USDs > ============================== > > The userspace driver scenario discussed in that thread involves a > primary process driving a PCIe function through VFIO/iommufd, which > manages the function-wide ownership/lifecycle. The function is > designed to provide multiple distinct programming interfaces (for > example, several independent MMIO register frames in one function), > and the primary process delegates control of these interfaces to > multiple independent client processes (which do the actual work). > This scenario clearly relies on a HW design that provides appropriate > isolation between the programming interfaces. > > The two key needs are: > > 1. Mechanisms to safely delegate a subset of the device MMIO > resources to a client process without over-sharing wider access > (or influence over whole-device activities, such as reset). > > 2. Mechanisms to allow a client process to do its own iommufd > management w.r.t. its address space, in a way that's isolated > from DMA relating to other clients. > > > mmap() of VFIO DMABUFs > ====================== > > This RFC addresses #1 in "vfio/pci: Support mmap() of a VFIO DMABUF", > implementing the proposals in [0] to add mmap() support to the > existing VFIO DMABUF exporter. > > This enables a userspace driver to define DMABUF ranges corresponding > to sub-ranges of a BAR, and grant a given client (via a shared fd) > the capability to access (only) those sub-ranges. The VFIO device fds > would be kept private to the primary process. All the client can do > with that fd is map (or iomap via iommufd) that specific subset of > resources, and the impact of bugs/malice is contained. > > (We'll follow up on #2 separately, as a related-but-distinct problem. > PASIDs are one way to achieve per-client isolation of DMA; another > could be sharing of a single IOVA space via 'constrained' iommufds.) > > > New in v2: To achieve this, the existing VFIO BAR mmap() path is > converted to use DMABUFs behind the scenes, in "vfio/pci: Convert BAR > mmap() to use a DMABUF" plus new helper functions, as Jason/Christian > suggested in the v1 discussion [3]. > > This means: > > - Both regular and new DMABUF BAR mappings share the same vm_ops, > i.e. mmap()ing DMABUFs is a smaller change on top of the existing > mmap(). > > - The zapping of mappings occurs via vfio_pci_dma_buf_move(), and the > vfio_pci_zap_bars() originally paired with the _move()s can go > away. Each DMABUF has a unique address_space. > > - It's a step towards future iommufd VFIO Type1 emulation > implementing P2P, since iommufd can now get a DMABUF from a VA that > it's mapping for IO; the VMAs' vm_file is that of the backing > DMABUF. > > > Revocation/reclaim > ================== > > Mapping a BAR subset is useful, but the lifetime of access granted to > a client needs to be managed well. For example, a protocol between > the primary process and the client can indicate when the client is > done, and when it's safe to reuse the resources elsewhere, but cleanup > can't practically be cooperative. > > For robustness, we enable the driver to make the resources > guaranteed-inaccessible when it chooses, so that it can re-assign them > to other uses in future. > > "vfio/pci: Permanently revoke a DMABUF on request" adds a new VFIO > device fd ioctl, VFIO_DEVICE_PCI_DMABUF_REVOKE. This takes a DMABUF > fd parameter previously exported (from that device!) and permanently > revokes the DMABUF. This notifies/detaches importers, zaps PTEs for > any mappings, and guarantees no future attachment/import/map/access is > possible by any means. > > A primary driver process would use this operation when the client's > tenure ends to reclaim "loaned-out" MMIO interfaces, at which point > the interfaces could be safely re-used. > > New in v2: ioctl() on VFIO driver fd, rather than DMABUF fd. A DMABUF > is revoked using code common to vfio_pci_dma_buf_move(), selectively > zapping mappings (after waiting for completion on the > dma_buf_invalidate_mappings() request). > > > BAR mapping access attributes > ============================= > > Inspired by Alex [Mastro] and Jason's comments in [0] and Mahmoud's > work in [1] with the goal of controlling CPU access attributes for > VFIO BAR mappings (e.g. WC), we can decorate DMABUFs with access > attributes that are then used by a mapping's PTEs. > > I've proposed reserving a field in struct > vfio_device_feature_dma_buf's flags to specify an attribute for its > ranges. Although that keeps the (UAPI) struct unchanged, it means all > ranges in a DMABUF share the same attribute. I feel a single > attribute-to-mmap() relation is logical/reasonable. An application > can also create multiple DMABUFs to describe any BAR layout and mix of > attributes. > > > Tests > ===== > > (Still sharing the [RFC ONLY] userspace test/demo program for context, > not for merge.) > > It illustrates & tests various map/revoke cases, but doesn't use the > existing VFIO selftests and relies on a (tweaked) QEMU EDU function. > I'm (still) working on integrating the scenarios into the existing > VFIO selftests. > > This code has been tested in mapping DMABUFs of single/multiple > ranges, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings seem > to work correctly. I've lightly tested WC mappings also (by observing > resulting PTEs as having the correct attributes...). > > > Fin > === > > v2 is based on next-20260310 (to build on Leon's recent series > "vfio: Wait for dma-buf invalidation to complete" [2]). > > > Please share your thoughts! I'd like to de-RFC if we feel this > approach is now fair. I only skimmed over it, but at least of hand I couldn't find anything fundamentally wrong. The locking order seems to change in patch #6. In general I strongly recommend to enable lockdep while testing anyway but explicitly when I see such changes. Additional to that it might also be a good idea to have a lockdep initcall function which defines the locking order in the way all the VFIO code should follow. See function dma_resv_lockdep() for an example on how to do that. Especially with mmap support and all the locks involved with that it has proven to be a good practice to have something like that. Regards, Christian. > > > Many thanks, > > > Matt > > > > References: > > [0]: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ > [1]: https://lore.kernel.org/all/20250804104012.87915-1-mngyadam@amazon.de/ > [2]: https://lore.kernel.org/linux-iommu/20260205-nocturnal-poetic-chamois-f566a… > [3]: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ > > -------------------------------------------------------------------------------- > Changelog: > > v2: Respin based on the feedback/suggestions: > > - Transform the existing VFIO BAR mmap path to also use DMABUFs behind > the scenes, and then simply share that code for explicitly-mapped > DMABUFs. > > - Refactors the export itself out of vfio_pci_core_feature_dma_buf, > and shared by a new vfio_pci_core_mmap_prep_dmabuf helper used by > the regular VFIO mmap to create a DMABUF. > > - Revoke buffers using a VFIO device fd ioctl > > v1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ > > > Matt Evans (10): > vfio/pci: Set up VFIO barmap before creating a DMABUF > vfio/pci: Clean up DMABUFs before disabling function > vfio/pci: Add helper to look up PFNs for DMABUFs > vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA > vfio/pci: Convert BAR mmap() to use a DMABUF > vfio/pci: Remove vfio_pci_zap_bars() > vfio/pci: Support mmap() of a VFIO DMABUF > vfio/pci: Permanently revoke a DMABUF on request > vfio/pci: Add mmap() attributes to DMABUF feature > [RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test > > drivers/vfio/pci/Kconfig | 3 +- > drivers/vfio/pci/Makefile | 3 +- > drivers/vfio/pci/vfio_pci_config.c | 18 +- > drivers/vfio/pci/vfio_pci_core.c | 123 +-- > drivers/vfio/pci/vfio_pci_dmabuf.c | 425 +++++++-- > drivers/vfio/pci/vfio_pci_priv.h | 46 +- > include/uapi/linux/vfio.h | 42 +- > tools/testing/selftests/vfio/Makefile | 1 + > .../vfio/standalone/vfio_dmabuf_mmap_test.c | 837 ++++++++++++++++++ > 9 files changed, 1339 insertions(+), 159 deletions(-) > create mode 100644 tools/testing/selftests/vfio/standalone/vfio_dmabuf_mmap_test.c >

2 weeks, 1 day

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig