lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Oct 2023 13:42:30 +0100
From:   Marc Zyngier <>
To:     Jan Henrik Weinstock <>
        Lukas J√ľnger <>
Subject: Re: KVM exit to userspace on WFI

On Wed, 25 Oct 2023 13:12:14 +0100,
Jan Henrik Weinstock <> 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.
> 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

> 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.



Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists