On Mon, Apr 3, 2023 at 10:23 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 4/3/23 07:05, Lai Jiangshan wrote: > > 2.3 #VE > > ------- > > > > The approach for fixing the kernel mode #VE recursion issue is to just > > NOT use IST for #VE although #VE is also considered to be one of the > > super exceptions and had raised some worries: > > https://lore.kernel.org/lkml/YCEQiDNSHTGBXBcj@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > https://lore.kernel.org/lkml/CALCETrU9XypKbj-TrXLB3CPW6=MZ__5ifLz0ckbB=c=Myegn9Q@xxxxxxxxxxxxxx/ > > https://lore.kernel.org/lkml/1843debc-05e8-4d10-73e4-7ddce3b3eae2@xxxxxxxxx/ > > > > To remit the worries, SEPT_VE_DISABLE is forced used currently and > > also disables its abilities (accept-on-demand or memory balloon which > > is critical to lightweight VMs like Kata Containers): > > https://lore.kernel.org/lkml/YCb0%2FDg28uI7TRD%2F@xxxxxxxxxx/ > > You don't need #VE for accept-on-demand. Pages go through _very_ > well-defined software choke points before they get used *and* before > they get ballooned. Thus: > > > https://lore.kernel.org/lkml/20230330114956.20342-3-kirill.shutemov@xxxxxxxxxxxxxxx/ > Thanks for the information. I will have a look to see how it supports memory balloons. And if accept-on-demand were supported, do we still need this CONFIG_UNACCEPTED_MEMORY? > BTW, _who_ considers #VE to be a "super exception"? Can you explain how > it is any more "super" than #PF? #PF can recurse. You can take #PF in > the entry paths. > > I kinda don't think you should be using TDX and #VE as part of the > justification for this series. You are right, #VE is not a super exception anymore since SEPT_VE_DISABLE is forced set in the Linux kernel and it is nothing to do with this series. But #VE was once thought to be a super exception (I will correct the sentence in the cover letter), so it is worth mentioning it. And since SEPT_VE_DISABLE is configurable, it would allow some paranoids to have a try with SEPT_VE_DISABLE=false even without FRED. The paranoids can try it with IST #VE. Thanks Lai