On 1/5/22 8:06 AM, Tom Lendacky wrote:
On 1/4/22 4:49 PM, Kirill A. Shutemov wrote:
Hi Tom,
For larger TDX VM, memset() after set_memory_decrypted() in
swiotlb_update_mem_attributes() takes substantial portion of boot time.
It makes me wounder why do we need it there? Malicious VMM can mess wi
On Wed, Jan 05, 2022 at 06:12:34AM -0800, Christoph Hellwig wrote:
> On Wed, Jan 05, 2022 at 08:06:10AM -0600, Tom Lendacky wrote:
> > On 1/4/22 4:49 PM, Kirill A. Shutemov wrote:
> > > Hi Tom,
> > >
> > > For larger TDX VM, memset() after set_memory_decrypted() in
> > > swiotlb_update_mem_attribu
On Wed, Jan 05, 2022 at 08:06:10AM -0600, Tom Lendacky wrote:
> On 1/4/22 4:49 PM, Kirill A. Shutemov wrote:
> > Hi Tom,
> >
> > For larger TDX VM, memset() after set_memory_decrypted() in
> > swiotlb_update_mem_attributes() takes substantial portion of boot time.
> >
> > It makes me wounder why
On 1/4/22 4:49 PM, Kirill A. Shutemov wrote:
Hi Tom,
For larger TDX VM, memset() after set_memory_decrypted() in
swiotlb_update_mem_attributes() takes substantial portion of boot time.
It makes me wounder why do we need it there? Malicious VMM can mess with
decrypted/shared buffer at any point
Hi Tom,
For larger TDX VM, memset() after set_memory_decrypted() in
swiotlb_update_mem_attributes() takes substantial portion of boot time.
It makes me wounder why do we need it there? Malicious VMM can mess with
decrypted/shared buffer at any point and for normal use it will be
populated with re
