On Fri, Jan 5, 2024 at 8:51 AM Zack Rusin <zack.rusin@xxxxxxxxxxxx> wrote: > > Some drivers require the mapped tt pages to be decrypted. In an ideal > world this would have been handled by the dma layer, but the TTM page > fault handling would have to be rewritten to able to do that. > > A side-effect of the TTM page fault handling is using a dma allocation > per order (via ttm_pool_alloc_page) which makes it impossible to just > trivially use dma_mmap_attrs. As a result ttm has to be very careful > about trying to make its pgprot for the mapped tt pages match what > the dma layer thinks it is. At the ttm layer it's possible to > deduce the requirement to have tt pages decrypted by checking > whether coherent dma allocations have been requested and the system > is running with confidential computing technologies. > > This approach isn't ideal but keeping TTM matching DMAs expectations > for the page properties is in general fragile, unfortunately proper > fix would require a rewrite of TTM's page fault handling. > > Fixes vmwgfx with SEV enabled. > > v2: Explicitly include cc_platform.h > v3: Use CC_ATTR_GUEST_MEM_ENCRYPT instead of CC_ATTR_MEM_ENCRYPT to > limit the scope to guests and log when memory decryption is enabled. Sorry, this also got a bit lost during the s/VMware/Broadcom/ transition. It seems to be pretty safe in general now. I wasn't able to find a really clean way of adding a warn_once when pte's don't match as suggested by Thomas, but I did add a quick log to at least point out in the logs that we've enabled memory decryption in tt. z
