[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee1949b33915ed8a80aa8318435595feee88a538.camel@intel.com>
Date: Mon, 12 Jun 2023 10:56:19 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "Williams, Dan J" <dan.j.williams@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"chao.p.peng@...ux.intel.com" <chao.p.peng@...ux.intel.com>
CC: "Hansen, Dave" <dave.hansen@...el.com>,
"david@...hat.com" <david@...hat.com>,
"bagasdotme@...il.com" <bagasdotme@...il.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"Luck, Tony" <tony.luck@...el.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"Shahar, Sagi" <sagis@...gle.com>,
"imammedo@...hat.com" <imammedo@...hat.com>,
"Gao, Chao" <chao.gao@...el.com>,
"Brown, Len" <len.brown@...el.com>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Huang, Ying" <ying.huang@...el.com>
Subject: Re: [PATCH v11 00/20] TDX host kernel support
On Thu, 2023-06-08 at 14:03 -0700, Dan Williams wrote:
> Kai Huang wrote:
> > Intel Trusted Domain Extensions (TDX) protects guest VMs from malicious
> > host and certain physical attacks. TDX specs are available in [1].
> >
> > This series is the initial support to enable TDX with minimal code to
> > allow KVM to create and run TDX guests. KVM support for TDX is being
> > developed separately[2]. A new "userspace inaccessible memfd" approach
> > to support TDX private memory is also being developed[3]. The KVM will
> > only support the new "userspace inaccessible memfd" as TDX guest memory.
>
> This memfd approach is incompatible with one of the primary ways that
> new memory topologies like high-bandwidth-memory and CXL are accessed,
> via a device-special-file mapping. There is already precedent for mmap()
> to only be used for communicating address value and not CPU accessible
> memory. See "Userspace P2PDMA with O_DIRECT NVMe devices" [1].
>
> So before this memfd requirement becomes too baked in to the design I
> want to understand if "userspace inaccessible" is the only requirement
> so I can look to add that to the device-special-file interface for
> "device" / "Soft Reserved" memory like HBM and CXL.
>
> [1]: https://lore.kernel.org/all/20221021174116.7200-1-logang@deltatee.com/
+ Peng, Chao who is working on this with Sean.
There are some recent developments around the design of the "userspace
inaccessible memfd", e.g., IIUC Sean is proposing to replace the new syscall
with a new KVM ioctl().
Hi Sean, Chao,
Could you give comments to Dan's concern?
Powered by blists - more mailing lists