On Tue, May 17, 2022 at 4:30 AM Wei Zhang <zhanwei@xxxxxxxxxx> wrote: > > > Please don't top-post. From https://people.kernel.org/tglx/notes-about-netiquette: > > Ah, I didn't know this should be avoided. Thanks for the info! > > > My preference would be to find a more complete, KVM-specific solution. The > > profiling stuff seems like it's a dead end, i.e. will always be flawed in some > > way. If this cleanup didn't require a new hypercall then I wouldn't care, but > > I don't love having to extend KVM's guest/host ABI for something that ideally > > will become obsolete sooner than later. > > I also feel that adding a new hypercall is too much here. A > KVM-specific solution is definitely better, and the eBPF based > approach you mentioned sounds like the ultimate solution (at least for > inspecting exit reasons). > > +Suleiman What do you think? The on-going work Sean described sounds > promising, perhaps we should put this patch aside for the time being. I'm ok with that. That said, the advantage of the current solution is that it already exists and is very easy to use, by anyone, without having to write any code. The proposed solution doesn't sound like it will be as easy. Regarding the earlier question about wanting to know which instructions trigger exits, most times I've needed to get exit profiles, I actually wanted to know where the guest was at the time of the exit, regardless of who triggered the exit. -- Suleiman
