From: Christoph Hellwig <hch@infradead.org> To: "Thomas Hellström (VMware)" <thomas_os@shipmail.org> Cc: "Andy Lutomirski" <luto@amacapital.net>, "Andy Lutomirski" <luto@kernel.org>, "Dave Hansen" <dave.hansen@intel.com>, "Daniel Vetter" <daniel@ffwll.ch>, dri-devel <dri-devel@lists.freedesktop.org>, pv-drivers@vmware.com, "VMware Graphics" <linux-graphics-maintainer@vmware.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Tom Lendacky" <thomas.lendacky@amd.com>, "Thomas Hellstrom" <thellstrom@vmware.com>, "Peter Zijlstra" <peterz@infradead.org>, "Dave Hansen" <dave.hansen@linux.intel.com>, "Heiko Carstens" <heiko.carstens@de.ibm.com>, "Christian Borntraeger" <borntraeger@de.ibm.com>, "Ingo Molnar" <mingo@redhat.com>, "Borislav Petkov" <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, "Thomas Gleixner" <tglx@linutronix.de>, "Christian König" <christian.koenig@amd.com> Subject: Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption Date: Wed, 4 Sep 2019 11:16:37 -0700 [thread overview] Message-ID: <20190904181637.GA26475@infradead.org> (raw) In-Reply-To: <3393108b-c7e3-c9be-b65b-5860c15ca228@shipmail.org> On Wed, Sep 04, 2019 at 08:49:03AM +0200, Thomas Hellström (VMware) wrote: > For device DMA address purposes, the encryption status is encoded in the dma > address by the dma layer in phys_to_dma(). > > > > There doesn’t seem to be any real funny business in dma_mmap_attrs() or dma_common_mmap(). > > No, from what I can tell the call in these functions to dma_pgprot() > generates an incorrect page protection since it doesn't take unencrypted > coherent memory into account. I don't think anybody has used these functions > yet with SEV. Yes, I think dma_pgprot is not correct for SEV. Right now that function isn't used much on x86, it had more grave bugs up to a few -rcs ago.. > > Would it make sense to add a vmf_insert_dma_page() to directly do exactly what you’re trying to do? > > Yes, but as a longer term solution I would prefer a general dma_pgprot() > exported, so that we could, in a dma-compliant way, use coherent pages with > other apis, like kmap_atomic_prot() and vmap(). That is, basically split > coherent page allocation in two steps: Allocation and mapping. The thing is that dma_pgprot is of no help for you at all, as the DMA API hides the page from you entirely. In fact we do have backends that do not even have a page backing. But I think we can have a vmf_insert_page equivalent that does the right thing behind your back for the varius different implementation (contiguous page(s) in the kernel lineary, contiguous page(s) with a vmap/ioremap remapping in various flavours, non-contigous pages(s) with a vmap remapping, and deeply magic firmware populated pools (well, except maybe for the last, but at least we can fail gracefully there)).
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: "Thomas Hellström (VMware)" <thomas_os@shipmail.org> Cc: "Andy Lutomirski" <luto@amacapital.net>, "Andy Lutomirski" <luto@kernel.org>, "Dave Hansen" <dave.hansen@intel.com>, "Daniel Vetter" <daniel@ffwll.ch>, dri-devel <dri-devel@lists.freedesktop.org>, pv-drivers@vmware.com, "VMware Graphics" <linux-graphics-maintainer@vmware.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Tom Lendacky" <thomas.lendacky@amd.com>, "Thomas Hellstrom" <thellstrom@vmware.com>, "Peter Zijlstra" <peterz@infradead.org>, "Dave Hansen" <dave.hansen@linux.intel.com>, "Heiko Carstens" <heiko.carstens@de.ibm.com>, "Christian Borntraeger" <borntraeger@de.ibm.com>, "Ingo Molnar" <mingo@redhat.com>, "Borislav Petkov" <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, "Thomas Gleixner" <tglx@linutronix.de> Subject: Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption Date: Wed, 4 Sep 2019 11:16:37 -0700 [thread overview] Message-ID: <20190904181637.GA26475@infradead.org> (raw) In-Reply-To: <3393108b-c7e3-c9be-b65b-5860c15ca228@shipmail.org> On Wed, Sep 04, 2019 at 08:49:03AM +0200, Thomas Hellström (VMware) wrote: > For device DMA address purposes, the encryption status is encoded in the dma > address by the dma layer in phys_to_dma(). > > > > There doesn’t seem to be any real funny business in dma_mmap_attrs() or dma_common_mmap(). > > No, from what I can tell the call in these functions to dma_pgprot() > generates an incorrect page protection since it doesn't take unencrypted > coherent memory into account. I don't think anybody has used these functions > yet with SEV. Yes, I think dma_pgprot is not correct for SEV. Right now that function isn't used much on x86, it had more grave bugs up to a few -rcs ago.. > > Would it make sense to add a vmf_insert_dma_page() to directly do exactly what you’re trying to do? > > Yes, but as a longer term solution I would prefer a general dma_pgprot() > exported, so that we could, in a dma-compliant way, use coherent pages with > other apis, like kmap_atomic_prot() and vmap(). That is, basically split > coherent page allocation in two steps: Allocation and mapping. The thing is that dma_pgprot is of no help for you at all, as the DMA API hides the page from you entirely. In fact we do have backends that do not even have a page backing. But I think we can have a vmf_insert_page equivalent that does the right thing behind your back for the varius different implementation (contiguous page(s) in the kernel lineary, contiguous page(s) with a vmap/ioremap remapping in various flavours, non-contigous pages(s) with a vmap remapping, and deeply magic firmware populated pools (well, except maybe for the last, but at least we can fail gracefully there)).
next prev parent reply other threads:[~2019-09-04 18:16 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-03 13:15 [PATCH v2 0/4] Have TTM support SEV encryption with coherent memory Thomas Hellström (VMware) 2019-09-03 13:15 ` [PATCH v2 1/4] x86/mm: Export force_dma_unencrypted Thomas Hellström (VMware) 2019-09-03 13:46 ` Christoph Hellwig 2019-09-03 14:32 ` Thomas Hellström (VMware) 2019-09-03 16:22 ` Christoph Hellwig 2019-09-03 16:22 ` Christoph Hellwig 2019-09-03 20:46 ` Thomas Hellström (VMware) 2019-09-03 20:46 ` Thomas Hellström (VMware) 2019-09-03 21:41 ` Andy Lutomirski 2019-09-04 6:58 ` Christoph Hellwig 2019-09-04 7:32 ` Thomas Hellström (VMware) 2019-09-04 12:22 ` Christoph Hellwig 2019-09-04 17:28 ` Thomas Hellström (VMware) 2019-09-03 15:14 ` Dave Hansen 2019-09-03 15:14 ` Dave Hansen 2019-09-03 18:50 ` Thomas Hellström (VMware) 2019-09-03 18:50 ` Thomas Hellström (VMware) 2019-09-03 13:15 ` [PATCH v2 2/4] s390/mm: " Thomas Hellström (VMware) 2019-09-03 13:46 ` Christoph Hellwig 2019-09-03 13:15 ` [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption Thomas Hellström (VMware) 2019-09-03 19:38 ` Dave Hansen 2019-09-03 19:51 ` Daniel Vetter 2019-09-03 19:51 ` Daniel Vetter 2019-09-03 19:55 ` Dave Hansen 2019-09-03 20:36 ` Thomas Hellström (VMware) 2019-09-03 20:51 ` Dave Hansen 2019-09-03 21:05 ` Thomas Hellström (VMware) 2019-09-03 21:46 ` Andy Lutomirski 2019-09-03 22:08 ` Thomas Hellström (VMware) 2019-09-03 22:15 ` Thomas Hellström (VMware) 2019-09-03 22:15 ` Thomas Hellström (VMware) 2019-09-03 23:10 ` Dave Hansen 2019-09-04 8:34 ` Thomas Hellström (VMware) 2019-09-03 23:15 ` Andy Lutomirski 2019-09-04 6:49 ` Thomas Hellström (VMware) 2019-09-04 7:53 ` Daniel Vetter 2019-09-04 10:37 ` Thomas Hellström (VMware) 2019-09-04 10:37 ` Thomas Hellström (VMware) 2019-09-04 11:43 ` Daniel Vetter 2019-09-04 18:16 ` Christoph Hellwig [this message] 2019-09-04 18:16 ` Christoph Hellwig 2019-09-04 7:33 ` Koenig, Christian 2019-09-04 8:19 ` Thomas Hellström (VMware) 2019-09-04 8:42 ` Thomas Hellström (VMware) 2019-09-04 8:42 ` Thomas Hellström (VMware) 2019-09-04 11:10 ` Koenig, Christian 2019-09-04 11:10 ` Koenig, Christian 2019-09-04 12:35 ` Thomas Hellström (VMware) 2019-09-04 12:35 ` Thomas Hellström (VMware) 2019-09-04 13:05 ` Thomas Hellström (VMware) 2019-09-03 13:15 ` [PATCH v2 4/4] drm/ttm: Cache dma pool decrypted pages when AMD SEV is active Thomas Hellström (VMware) 2019-09-03 15:18 ` [PATCH v2 0/4] Have TTM support SEV encryption with coherent memory Daniel Vetter 2019-09-05 10:43 ` Thomas Hellström (VMware)
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190904181637.GA26475@infradead.org \ --to=hch@infradead.org \ --cc=borntraeger@de.ibm.com \ --cc=bp@alien8.de \ --cc=christian.koenig@amd.com \ --cc=daniel@ffwll.ch \ --cc=dave.hansen@intel.com \ --cc=dave.hansen@linux.intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=heiko.carstens@de.ibm.com \ --cc=hpa@zytor.com \ --cc=linux-graphics-maintainer@vmware.com \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=luto@kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=pv-drivers@vmware.com \ --cc=tglx@linutronix.de \ --cc=thellstrom@vmware.com \ --cc=thomas.lendacky@amd.com \ --cc=thomas_os@shipmail.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.