All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@google.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: Alexandru Elisei <Alexandru.Elisei@arm.com>,
	salil.mehta@huawei.com, lorenzo.pieralisi@arm.com,
	kvm@vger.kernel.org, corbet@lwn.net, maz@kernel.org,
	linux-kernel@vger.kernel.org, jonathan.cameron@huawei.com,
	catalin.marinas@arm.com, pbonzini@redhat.com, will@kernel.org,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 0/5] KVM: arm64: Pass PSCI to userspace
Date: Mon, 19 Jul 2021 12:37:52 -0700	[thread overview]
Message-ID: <CAOQ_QsjyP0PMGOorTss2Fpn011mHPwVqQ72x26Gs2L0bg2amsQ@mail.gmail.com> (raw)
In-Reply-To: <YPW+Hv3r586zKxpY@myrica>

On Mon, Jul 19, 2021 at 11:02 AM Jean-Philippe Brucker
<jean-philippe@linaro.org> wrote:
> We forward the whole PSCI function range, so it's either KVM or userspace.
> If KVM manages PSCI and the guest calls an unimplemented function, that
> returns directly to the guest without going to userspace.
>
> The concern is valid for any other range, though. If userspace enables the
> HVC cap it receives function calls that at some point KVM might need to
> handle itself. So we need some negotiation between user and KVM about the
> specific HVC ranges that userspace can and will handle.

Are we going to use KVM_CAPs for every interesting HVC range that
userspace may want to trap? I wonder if a more generic interface for
hypercall filtering would have merit to handle the aforementioned
cases, and whatever else a VMM will want to intercept down the line.

For example, x86 has the concept of 'MSR filtering', wherein userspace
can specify a set of registers that it wants to intercept. Doing
something similar for HVCs would avoid the need for a kernel change
each time a VMM wishes to intercept a new hypercall.

--
Thanks,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oupton@google.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: salil.mehta@huawei.com, lorenzo.pieralisi@arm.com,
	catalin.marinas@arm.com, kvm@vger.kernel.org, corbet@lwn.net,
	maz@kernel.org, linux-kernel@vger.kernel.org, will@kernel.org,
	jonathan.cameron@huawei.com, pbonzini@redhat.com,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 0/5] KVM: arm64: Pass PSCI to userspace
Date: Mon, 19 Jul 2021 12:37:52 -0700	[thread overview]
Message-ID: <CAOQ_QsjyP0PMGOorTss2Fpn011mHPwVqQ72x26Gs2L0bg2amsQ@mail.gmail.com> (raw)
In-Reply-To: <YPW+Hv3r586zKxpY@myrica>

On Mon, Jul 19, 2021 at 11:02 AM Jean-Philippe Brucker
<jean-philippe@linaro.org> wrote:
> We forward the whole PSCI function range, so it's either KVM or userspace.
> If KVM manages PSCI and the guest calls an unimplemented function, that
> returns directly to the guest without going to userspace.
>
> The concern is valid for any other range, though. If userspace enables the
> HVC cap it receives function calls that at some point KVM might need to
> handle itself. So we need some negotiation between user and KVM about the
> specific HVC ranges that userspace can and will handle.

Are we going to use KVM_CAPs for every interesting HVC range that
userspace may want to trap? I wonder if a more generic interface for
hypercall filtering would have merit to handle the aforementioned
cases, and whatever else a VMM will want to intercept down the line.

For example, x86 has the concept of 'MSR filtering', wherein userspace
can specify a set of registers that it wants to intercept. Doing
something similar for HVCs would avoid the need for a kernel change
each time a VMM wishes to intercept a new hypercall.

--
Thanks,
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oupton@google.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: Alexandru Elisei <Alexandru.Elisei@arm.com>,
	salil.mehta@huawei.com,  lorenzo.pieralisi@arm.com,
	kvm@vger.kernel.org, corbet@lwn.net,  maz@kernel.org,
	linux-kernel@vger.kernel.org, jonathan.cameron@huawei.com,
	 catalin.marinas@arm.com, pbonzini@redhat.com, will@kernel.org,
	 kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 0/5] KVM: arm64: Pass PSCI to userspace
Date: Mon, 19 Jul 2021 12:37:52 -0700	[thread overview]
Message-ID: <CAOQ_QsjyP0PMGOorTss2Fpn011mHPwVqQ72x26Gs2L0bg2amsQ@mail.gmail.com> (raw)
In-Reply-To: <YPW+Hv3r586zKxpY@myrica>

On Mon, Jul 19, 2021 at 11:02 AM Jean-Philippe Brucker
<jean-philippe@linaro.org> wrote:
> We forward the whole PSCI function range, so it's either KVM or userspace.
> If KVM manages PSCI and the guest calls an unimplemented function, that
> returns directly to the guest without going to userspace.
>
> The concern is valid for any other range, though. If userspace enables the
> HVC cap it receives function calls that at some point KVM might need to
> handle itself. So we need some negotiation between user and KVM about the
> specific HVC ranges that userspace can and will handle.

Are we going to use KVM_CAPs for every interesting HVC range that
userspace may want to trap? I wonder if a more generic interface for
hypercall filtering would have merit to handle the aforementioned
cases, and whatever else a VMM will want to intercept down the line.

For example, x86 has the concept of 'MSR filtering', wherein userspace
can specify a set of registers that it wants to intercept. Doing
something similar for HVCs would avoid the need for a kernel change
each time a VMM wishes to intercept a new hypercall.

--
Thanks,
Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-19 20:18 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08 15:48 [RFC PATCH 0/5] KVM: arm64: Pass PSCI to userspace Jean-Philippe Brucker
2021-06-08 15:48 ` Jean-Philippe Brucker
2021-06-08 15:48 ` Jean-Philippe Brucker
2021-06-08 15:48 ` [RFC PATCH 1/5] KVM: arm64: Replace power_off with mp_state in struct kvm_vcpu_arch Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-06-10 15:08   ` Jonathan Cameron
2021-06-10 15:08     ` Jonathan Cameron
2021-06-10 15:08     ` Jonathan Cameron
2021-07-01  9:44   ` Fuad Tabba
2021-07-01  9:44     ` Fuad Tabba
2021-07-01  9:44     ` Fuad Tabba
2021-06-08 15:48 ` [RFC PATCH 2/5] KVM: arm64: Move WFI execution to check_vcpu_requests() Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-07-01  9:45   ` Fuad Tabba
2021-07-01  9:45     ` Fuad Tabba
2021-07-01  9:45     ` Fuad Tabba
2021-06-08 15:48 ` [RFC PATCH 3/5] KVM: arm64: Allow userspace to request WFI Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-07-01  9:45   ` Fuad Tabba
2021-07-01  9:45     ` Fuad Tabba
2021-07-01  9:45     ` Fuad Tabba
2021-06-08 15:48 ` [RFC PATCH 4/5] KVM: arm64: Pass hypercalls to userspace Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-06-10 16:02   ` Jonathan Cameron
2021-06-10 16:02     ` Jonathan Cameron
2021-06-10 16:02     ` Jonathan Cameron
2021-07-01  9:46   ` Fuad Tabba
2021-07-01  9:46     ` Fuad Tabba
2021-07-01  9:46     ` Fuad Tabba
2021-07-01  9:54   ` Russell King (Oracle)
2021-07-01  9:54     ` Russell King (Oracle)
2021-07-01  9:54     ` Russell King (Oracle)
2021-06-08 15:48 ` [RFC PATCH 5/5] KVM: arm64: Pass PSCI calls " Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-06-08 15:48   ` Jean-Philippe Brucker
2021-07-01  9:46   ` Fuad Tabba
2021-07-01  9:46     ` Fuad Tabba
2021-07-01  9:46     ` Fuad Tabba
2021-07-19 15:29 ` [RFC PATCH 0/5] KVM: arm64: Pass PSCI " Alexandru Elisei
2021-07-19 15:29   ` Alexandru Elisei
2021-07-19 15:29   ` Alexandru Elisei
2021-07-19 18:02   ` Jean-Philippe Brucker
2021-07-19 18:02     ` Jean-Philippe Brucker
2021-07-19 18:02     ` Jean-Philippe Brucker
2021-07-19 19:37     ` Oliver Upton [this message]
2021-07-19 19:37       ` Oliver Upton
2021-07-19 19:37       ` Oliver Upton
2021-07-21 17:46       ` Jean-Philippe Brucker
2021-07-21 17:46         ` Jean-Philippe Brucker
2021-07-21 17:46         ` Jean-Philippe Brucker
2021-07-21 17:56 ` Jean-Philippe Brucker
2021-07-21 17:56   ` Jean-Philippe Brucker
2021-07-21 17:56   ` Jean-Philippe Brucker

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=CAOQ_QsjyP0PMGOorTss2Fpn011mHPwVqQ72x26Gs2L0bg2amsQ@mail.gmail.com \
    --to=oupton@google.com \
    --cc=Alexandru.Elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=jean-philippe@linaro.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=salil.mehta@huawei.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.