On Mon, Nov 04, 2024 at 10:35:53AM +0200, Kirill A. Shutemov wrote: > On Fri, Oct 25, 2024 at 04:56:41PM +0300, Kirill A. Shutemov wrote: > > On Wed, Oct 23, 2024 at 10:44:11AM -0500, Eric W. Biederman wrote: > > > "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> writes: > > > > > > > Waiting minutes to get VM booted to shell is not feasible for most > > > > deployments. Lazy is sane default to me. > > > > > > Huh? > > > > > > Unless my guesses about what is happening are wrong lazy is hiding > > > a serious implementation deficiency. From all hardware I have seen > > > taking minutes is absolutely ridiculous. > > > > > > Does writing to all of memory at full speed take minutes? How can such > > > a system be functional? > > > > It is not only memory write (to encrypt the memory), but also TDCALL which > > is TD-exit on every page. That is costly in TDX case. > > > > On single vCPU it takes about a minute to accept 90GiB of memory. > > > > It improves a bit with number of vCPUs. It is 40 seconds with 4 vCPU, but > > it doesn't scale past that in my setup. > > > > But it is all rather pathological: VMM doesn't support huge pages yet and > > all memory is accepted in 4K chunks. Bringing 2M support would cut number > > of TDCALLs by 512. > > > > Once memory accepted, memory access cost is comparable to bare metal minus > > usual virtualisation tax on page walk. > > > > I don't know what the picture looks like in AMD case. > > j > > > If you don't actually have to write to the pages and it is just some > > > accounting function it is even more ridiculous. > > > > > > > > > I had previously thought that accept_memory was the firmware call. > > > Now that I see that it is just a wrapper for some hardware specific > > > calls I am even more perplexed. > > > > It is hypercall basically. The feature is only used in guests so far. > > Eric, can we get the patch applied? It fixes a crash. Ping? -- Kiryl Shutsemau / Kirill A. Shutemov _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
