Messages in this thread | | | Date | Wed, 25 Oct 2023 13:42:30 +0100 | From | Marc Zyngier <> | Subject | Re: KVM exit to userspace on WFI |
| |
On Wed, 25 Oct 2023 13:12:14 +0100, Jan Henrik Weinstock <jan@mwa.re> wrote: > > Hi Marc, > > Thanks for your feedback. I understand that request_interrupt_window > is not to be used. I assume a setting a flag is a better way, > something similar to KVM_ARCH_FLAG_RETURN_NISV_IO_ABORT_TO_USER, e.g. > KVM_ARCH_FLAG_WFX_EXIT_TO_USER. > > I will also check that WFx traps are always enabled while this mode is > active to make sure userspace does not get blocked/scheduled out.
Why would that be an acceptable behaviour?
> The reason for this is that we cannot have the thread that executes > KVM_RUN to be blocked or scheduled out whenever it hits a WFI.
Why? If that's not acceptable, how do you even cope with the basic preemption?
> Nop-WFIs are not a problem, since the PE will just continue executing > instructions, which is fine. We are currently using a timeout signal > that kicks KVM_RUN back into userspace, but we are seeing a lot of > time wasted because our KVM thread hangs in WFI/WFEs. It would be > better if we could just return from KVM_RUN immediately if the thread > would otherwise be blocked.
On the face of it, this makes little sense:
- While in userspace, no interrupt source that normally delivered without any userpsace intervention will be blocked (timers, VLPIs...). I cannot how this can be a good idea.
- Trapping WFE is an important scheduling hint, and returning to userspace defeats it. Contended spinlocks, for example, will be even slower to acquire.
I'm sure you have a particular use case for such a degraded behaviour, but since you are not describing it, I'm not at all inclined to actively break KVM's performance and scalability.
Thanks,
M.
-- Without deviation from the norm, progress is not possible.
| |