public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Jan Henrik Weinstock <jan@mwa.re>
Cc: oliver.upton@linux.dev, james.morse@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com,
	catalin.marinas@arm.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, "Lukas Jünger" <lukas@mwa.re>
Subject: Re: KVM exit to userspace on WFI
Date: Mon, 30 Oct 2023 12:36:09 +0000	[thread overview]
Message-ID: <86msw01e4m.wl-maz@kernel.org> (raw)
In-Reply-To: <CANi1PHjAwLWAq9EW7r5Yh_xbvPiJMsq8342JwAGafz1d1NUhSA@mail.gmail.com>

[please make an effort not to top-post]

On Fri, 27 Oct 2023 18:41:44 +0100,
Jan Henrik Weinstock <jan@mwa.re> wrote:
> 
> Hi Marc,
> 
> the basic idea behind this is to have a (single-threaded) execution loop,
> something like this:
> 
> vcpu-thread:    vcpu-run | process-io-devices | vcpu-run | process-io...
>                          ^
>                   WFX or timeout
> 
> We switch to simulating IO devices whenever the vcpu is idle (wfi) or exceeds
> a certain budget of instructions (counted via pmu). Our fallback currently is
> to kick the vcpu out of its execution using a signal (via a timeout/alarm). But
> of course, if the cpu is stuck at a wfi, we are wasting a lot of time.
> 
> I understand that the proposed behavior is not desirable for most use cases,
> which is why I suggest locking it behind a flag, e.g.
> KVM_ARCH_FLAG_WFX_EXIT_TO_USER.

But how do you reconcile the fact that exposing this to userspace
breaks fundamental expectations that the guest has, such as getting
its timer interrupts and directly injected LPIs? Implementing WFI in
userspace breaks it. What about the case where we don't trap WFx and
let the *guest* wait for an interrupt?

Honestly, what you are describing seems to be a use model that doesn't
fit KVM, which is a general purpose hypervisor, but more a simulation
environment. Yes, the primitives are the same, but the plumbing is
wildly different.

*If* that's the stuff you're looking at, then I'm afraid you'll have
to do it in different way, because what you are suggesting is
fundamentally incompatible with the guarantees that KVM gives to guest
and userspace. Because your KVM_ARCH_FLAG_WFX_EXIT_TO_USER is really a
lie. It should really be named something more along the lines of
KVM_ARCH_FLAG_WFX_EXIT_TO_USER_SOMETIME_AND_I_DONT_EVEN_KNOW_WHEN
(probably with additional clauses related to breaking things).

Overall, you are still asking for something that is not guaranteed at
the architecture level, even less in KVM, and I'm not going to add
support for something that can only work "sometime".

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2023-10-30 12:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-20 18:45 KVM exit to userspace on WFI Jan Henrik Weinstock
2023-10-20 19:56 ` Marc Zyngier
2023-10-25 12:12   ` Jan Henrik Weinstock
2023-10-25 12:42     ` Marc Zyngier
2023-10-27 17:41       ` Jan Henrik Weinstock
2023-10-30 12:36         ` Marc Zyngier [this message]
2023-10-31 19:21           ` Jan Henrik Weinstock
2023-11-04 12:13             ` Marc Zyngier
2023-11-08  9:38               ` Jan Henrik Weinstock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86msw01e4m.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=jan@mwa.re \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@mwa.re \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox