On Tue, May 19, 2026 at 01:41:42PM +0000, Mostafa Saleh wrote: > On Tue, May 19, 2026 at 10:29:11AM -0300, Jason Gunthorpe wrote: > > On Tue, May 19, 2026 at 11:04:37AM +0000, Mostafa Saleh wrote: > > > On Thu, May 14, 2026 at 08:13:25PM +0530, Aneesh Kumar K.V wrote: > > > > >> > > > > >> What I meant was that we need a generic way to identify a pKVM > > > > >> guest, so > > > > >> that we can use it in the conditional above. > > > > > > > > > > I have this patch, with that I can boot with your series unmodified, > > > > > but I will need to do more testing. > > > > > > > > > > > > > Thanks, I can add this to the series once you complete the required > > > > testing. > > > > > > > > > > I am still running more tests, but looking more into it. Setting > > > force_dma_unencrypted() to true for pKVM guests is wrong, as the > > > guest shouldn’t try to decrypt arbitrary memory as it can include > > > sensitive information (for example in case of virtio sub-page > > > allocation) and should strictly rely on the restricted-dma-pool > > > for that. > > > > ?? > > > > Where does force_dma_unencrypted() cause arbitary memory passed into > > the DMA API to be decrypted? That should never happen??? > > Sorry, maybe arbitrary is not the right expression again :) > I mean that, with emulated devices that use the DMA-API under pKVM, > they will map memory coming from other layers (VFS, net) through > vitrio-block, virtio-net... These can be smaller than a page, and > using force_dma_unencrypted() will share the whole page.
force_dma_unencrypted() should only trigger swiotlb and that never memcpy's more than necessary? Where does it do otherwise? That sounds like a bug? Jason
