On 1/6/25 06:50, Yan Zhao wrote:
Yeah. So, do you think we need to have tdh_mem_page_aug() to support 4K level page only and ask for Dave's review again for huge page?
You're right that TDH.MEM.PAGE.AUG is basically the only case in which a struct folio is involved; on the other hand that also means that the arch/x86/virt part of large page support will be tiny and I don't think it will be a problem to review it again (for either Dave or myself).
Do we need to add param "level" ? - if yes, "struct page" looks not fit.
Maybe, but I think adding folio knowledge now would be a bit too hypothetical.
- if not, hardcode it as 0 in the wrapper and convert "pfn" to "struct page"?
I think it makes sense to add "int level" now everywhere, even if it is just to match the SEPT API and to have the same style for computing the SEAMCALL arguments. I'd rather keep the arguments simple with just "gpa | level" (i.e. gpa/level instead of gfn/level) as the computation: that's because gpa is more obviously a u64.
I've pushed to kvm-coco-queue; if you have some time to double check what I did that's great, otherwise if I don't hear from you I'll post around noon European time the v3 of this series.
I have also asked Amazon, since they use KVM without struct page, whether it is a problem to have struct page pervasively in the API and they don't care.
Paolo
