On Thu, 2022-10-27 at 16:51 +0300, Kirill A. Shutemov wrote: > On Thu, Oct 27, 2022 at 08:42:16AM +0000, Huang, Kai wrote: > > On Thu, 2022-10-27 at 15:08 +0800, Li, Xiaoyao wrote: > > > > @@ -663,27 +662,16 @@ static bool try_accept_one(phys_addr_t *start, > > > > unsigned long len, > > > > if (len < accept_size) > > > > return false; > > > > > > > > + /* TDX only supports 4K/2M/1G page sizes */ > > > > > > yes, a page can be mapped as 1G size to TD via secure/shared EPT. But > > > for this particular TDX_ACCEPT_PAGE case, it only supports 4K and 2M > > > currently, which is defined in TDX module spec. > > > > I checked the TDX module public spec, and it appears you are right. But I am > > not sure whether it will be changed in the future? > > The spec says: > > Level of the Secure EPT entry that maps the private page to be > accepted: either 0 (4KB) or 1 (2MB) – see 20.5.1 > > Yes, it is about 4k and 2M, but it also refers 20.5.1, which lists sizes > up to 16PB. Also, I think we are mixing two things: 1) leaf page sizes (4K/2M/1G); 2) page table levels. The latter has more levels than the former. For try_accept_one() (and TDX host code), we actually care only about the former. KVM needs the latter (or both), so it's better for KVM to handle on its own. > > Ultimately, it does not matter: if TDX module doesn't support the size or > cannot accept the memory for other reason guest kernel will fallback to > smaller size. > Yes.
