From: Marc Zyngier <maz@kernel.org>
To: Jason Wang <jasowang@redhat.com>
Cc: Raghavendra Rao Ananta <rananta@google.com>,
Andrew Jones <drjones@redhat.com>,
James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Peter Shier <pshier@google.com>,
Ricardo Koller <ricarkol@google.com>,
Oliver Upton <oupton@google.com>,
Reiji Watanabe <reijiw@google.com>,
Jing Zhang <jingzhangos@google.com>,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [RFC PATCH v3 04/11] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
Date: Wed, 19 Jan 2022 10:21:20 +0000 [thread overview]
Message-ID: <87ee5481r3.wl-maz@kernel.org> (raw)
In-Reply-To: <960d4166-1718-55ef-d324-507a8add7e3e@redhat.com>
On Wed, 19 Jan 2022 06:42:15 +0000,
Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2022/1/5 上午3:49, Raghavendra Rao Ananta 写道:
> > KVM regularly introduces new hypercall services to the guests without
> > any consent from the Virtual Machine Manager (VMM). This means, the
> > guests can observe hypercall services in and out as they migrate
> > across various host kernel versions. This could be a major problem
> > if the guest discovered a hypercall, started using it, and after
> > getting migrated to an older kernel realizes that it's no longer
> > available. Depending on how the guest handles the change, there's
> > a potential chance that the guest would just panic.
> >
> > As a result, there's a need for the VMM to elect the services that
> > it wishes the guest to discover. VMM can elect these services based
> > on the kernels spread across its (migration) fleet. To remedy this,
> > extend the existing firmware psuedo-registers, such as
> > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
>
>
>
> Haven't gone through the series but I wonder whether it's better to
> have a (e)BPF filter for this like seccomp.
No, please. This has to fit in the save/restore model, and should be
under control of the VMM. If you want to filter things using seccomp,
that's fine, but also that's completely orthogonal.
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Jason Wang <jasowang@redhat.com>
Cc: kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Peter Shier <pshier@google.com>,
linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v3 04/11] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
Date: Wed, 19 Jan 2022 10:21:20 +0000 [thread overview]
Message-ID: <87ee5481r3.wl-maz@kernel.org> (raw)
In-Reply-To: <960d4166-1718-55ef-d324-507a8add7e3e@redhat.com>
On Wed, 19 Jan 2022 06:42:15 +0000,
Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2022/1/5 上午3:49, Raghavendra Rao Ananta 写道:
> > KVM regularly introduces new hypercall services to the guests without
> > any consent from the Virtual Machine Manager (VMM). This means, the
> > guests can observe hypercall services in and out as they migrate
> > across various host kernel versions. This could be a major problem
> > if the guest discovered a hypercall, started using it, and after
> > getting migrated to an older kernel realizes that it's no longer
> > available. Depending on how the guest handles the change, there's
> > a potential chance that the guest would just panic.
> >
> > As a result, there's a need for the VMM to elect the services that
> > it wishes the guest to discover. VMM can elect these services based
> > on the kernels spread across its (migration) fleet. To remedy this,
> > extend the existing firmware psuedo-registers, such as
> > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
>
>
>
> Haven't gone through the series but I wonder whether it's better to
> have a (e)BPF filter for this like seccomp.
No, please. This has to fit in the save/restore model, and should be
under control of the VMM. If you want to filter things using seccomp,
that's fine, but also that's completely orthogonal.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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: Marc Zyngier <maz@kernel.org>
To: Jason Wang <jasowang@redhat.com>
Cc: Raghavendra Rao Ananta <rananta@google.com>,
Andrew Jones <drjones@redhat.com>,
James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Peter Shier <pshier@google.com>,
Ricardo Koller <ricarkol@google.com>,
Oliver Upton <oupton@google.com>,
Reiji Watanabe <reijiw@google.com>,
Jing Zhang <jingzhangos@google.com>,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [RFC PATCH v3 04/11] KVM: arm64: Setup a framework for hypercall bitmap firmware registers
Date: Wed, 19 Jan 2022 10:21:20 +0000 [thread overview]
Message-ID: <87ee5481r3.wl-maz@kernel.org> (raw)
In-Reply-To: <960d4166-1718-55ef-d324-507a8add7e3e@redhat.com>
On Wed, 19 Jan 2022 06:42:15 +0000,
Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2022/1/5 上午3:49, Raghavendra Rao Ananta 写道:
> > KVM regularly introduces new hypercall services to the guests without
> > any consent from the Virtual Machine Manager (VMM). This means, the
> > guests can observe hypercall services in and out as they migrate
> > across various host kernel versions. This could be a major problem
> > if the guest discovered a hypercall, started using it, and after
> > getting migrated to an older kernel realizes that it's no longer
> > available. Depending on how the guest handles the change, there's
> > a potential chance that the guest would just panic.
> >
> > As a result, there's a need for the VMM to elect the services that
> > it wishes the guest to discover. VMM can elect these services based
> > on the kernels spread across its (migration) fleet. To remedy this,
> > extend the existing firmware psuedo-registers, such as
> > KVM_REG_ARM_PSCI_VERSION, for all the hypercall services available.
>
>
>
> Haven't gone through the series but I wonder whether it's better to
> have a (e)BPF filter for this like seccomp.
No, please. This has to fit in the save/restore model, and should be
under control of the VMM. If you want to filter things using seccomp,
that's fine, but also that's completely orthogonal.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-19 10:21 UTC|newest]
Thread overview: 153+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 19:49 [RFC PATCH v3 00/11] KVM: arm64: Add support for hypercall services selection Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 01/11] KVM: Capture VM start Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-07 6:06 ` Reiji Watanabe
2022-01-07 6:06 ` Reiji Watanabe
2022-01-07 6:06 ` Reiji Watanabe
2022-01-07 23:43 ` Raghavendra Rao Ananta
2022-01-07 23:43 ` Raghavendra Rao Ananta
2022-01-07 23:43 ` Raghavendra Rao Ananta
2022-01-08 0:04 ` Jim Mattson
2022-01-08 0:04 ` Jim Mattson
2022-01-08 0:04 ` Jim Mattson
2022-01-10 23:07 ` Raghavendra Rao Ananta
2022-01-10 23:07 ` Raghavendra Rao Ananta
2022-01-10 23:07 ` Raghavendra Rao Ananta
2022-01-10 23:57 ` Jim Mattson
2022-01-10 23:57 ` Jim Mattson
2022-01-10 23:57 ` Jim Mattson
2022-01-11 18:52 ` Raghavendra Rao Ananta
2022-01-11 18:52 ` Raghavendra Rao Ananta
2022-01-11 18:52 ` Raghavendra Rao Ananta
2022-01-11 19:16 ` Jim Mattson
2022-01-11 19:16 ` Jim Mattson
2022-01-11 19:16 ` Jim Mattson
2022-01-12 18:29 ` Raghavendra Rao Ananta
2022-01-12 18:29 ` Raghavendra Rao Ananta
2022-01-12 18:29 ` Raghavendra Rao Ananta
2022-01-13 17:21 ` Sean Christopherson
2022-01-13 17:21 ` Sean Christopherson
2022-01-13 17:21 ` Sean Christopherson
2022-01-14 0:42 ` Raghavendra Rao Ananta
2022-01-14 0:42 ` Raghavendra Rao Ananta
2022-01-14 0:42 ` Raghavendra Rao Ananta
2022-01-14 1:10 ` Sean Christopherson
2022-01-14 1:10 ` Sean Christopherson
2022-01-14 1:10 ` Sean Christopherson
2022-01-14 21:51 ` Reiji Watanabe
2022-01-14 21:51 ` Reiji Watanabe
2022-01-14 21:51 ` Reiji Watanabe
2022-01-18 22:54 ` Raghavendra Rao Ananta
2022-01-18 22:54 ` Raghavendra Rao Ananta
2022-01-18 22:54 ` Raghavendra Rao Ananta
2022-01-19 0:07 ` Sean Christopherson
2022-01-19 0:07 ` Sean Christopherson
2022-01-19 0:07 ` Sean Christopherson
2022-01-19 7:47 ` Reiji Watanabe
2022-01-19 7:47 ` Reiji Watanabe
2022-01-19 7:47 ` Reiji Watanabe
2022-01-20 0:27 ` Sean Christopherson
2022-01-20 0:27 ` Sean Christopherson
2022-01-20 0:27 ` Sean Christopherson
2022-01-20 19:16 ` Raghavendra Rao Ananta
2022-01-20 19:16 ` Raghavendra Rao Ananta
2022-01-20 19:16 ` Raghavendra Rao Ananta
2022-01-25 15:15 ` Marc Zyngier
2022-01-25 15:15 ` Marc Zyngier
2022-01-25 15:15 ` Marc Zyngier
2022-01-25 15:10 ` Marc Zyngier
2022-01-25 15:10 ` Marc Zyngier
2022-01-25 15:10 ` Marc Zyngier
2022-01-11 0:03 ` Reiji Watanabe
2022-01-11 0:03 ` Reiji Watanabe
2022-01-11 0:03 ` Reiji Watanabe
2022-01-11 18:54 ` Raghavendra Rao Ananta
2022-01-11 18:54 ` Raghavendra Rao Ananta
2022-01-11 18:54 ` Raghavendra Rao Ananta
2022-01-08 1:06 ` Sean Christopherson
2022-01-08 1:06 ` Sean Christopherson
2022-01-08 1:06 ` Sean Christopherson
2022-01-10 23:23 ` Raghavendra Rao Ananta
2022-01-10 23:23 ` Raghavendra Rao Ananta
2022-01-10 23:23 ` Raghavendra Rao Ananta
2022-01-11 17:36 ` Sean Christopherson
2022-01-11 17:36 ` Sean Christopherson
2022-01-11 17:36 ` Sean Christopherson
2022-01-11 18:46 ` Raghavendra Rao Ananta
2022-01-11 18:46 ` Raghavendra Rao Ananta
2022-01-11 18:46 ` Raghavendra Rao Ananta
2022-01-11 19:04 ` Sean Christopherson
2022-01-11 19:04 ` Sean Christopherson
2022-01-11 19:04 ` Sean Christopherson
2022-01-12 18:08 ` Raghavendra Rao Ananta
2022-01-12 18:08 ` Raghavendra Rao Ananta
2022-01-12 18:08 ` Raghavendra Rao Ananta
2022-01-12 18:24 ` Sean Christopherson
2022-01-12 18:24 ` Sean Christopherson
2022-01-12 18:24 ` Sean Christopherson
2022-01-12 18:31 ` Sean Christopherson
2022-01-12 18:31 ` Sean Christopherson
2022-01-12 18:31 ` Sean Christopherson
2022-01-04 19:49 ` [RFC PATCH v3 02/11] KVM: arm64: Factor out firmware register handling from psci.c Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 03/11] KVM: Introduce KVM_CAP_ARM_HVC_FW_REG_BMAP Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-08 5:40 ` Reiji Watanabe
2022-01-08 5:40 ` Reiji Watanabe
2022-01-08 5:40 ` Reiji Watanabe
2022-01-10 23:40 ` Raghavendra Rao Ananta
2022-01-10 23:40 ` Raghavendra Rao Ananta
2022-01-10 23:40 ` Raghavendra Rao Ananta
2022-01-11 4:33 ` Reiji Watanabe
2022-01-11 4:33 ` Reiji Watanabe
2022-01-11 4:33 ` Reiji Watanabe
2022-01-04 19:49 ` [RFC PATCH v3 04/11] KVM: arm64: Setup a framework for hypercall bitmap firmware registers Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-10 6:28 ` Reiji Watanabe
2022-01-10 6:28 ` Reiji Watanabe
2022-01-10 6:28 ` Reiji Watanabe
2022-01-11 0:50 ` Raghavendra Rao Ananta
2022-01-11 0:50 ` Raghavendra Rao Ananta
2022-01-11 0:50 ` Raghavendra Rao Ananta
2022-01-12 5:11 ` Reiji Watanabe
2022-01-12 5:11 ` Reiji Watanabe
2022-01-12 5:11 ` Reiji Watanabe
2022-01-12 18:02 ` Raghavendra Rao Ananta
2022-01-12 18:02 ` Raghavendra Rao Ananta
2022-01-12 18:02 ` Raghavendra Rao Ananta
2022-01-14 6:23 ` Reiji Watanabe
2022-01-14 6:23 ` Reiji Watanabe
2022-01-14 6:23 ` Reiji Watanabe
2022-01-19 6:42 ` Jason Wang
2022-01-19 6:42 ` Jason Wang
2022-01-19 6:42 ` Jason Wang
2022-01-19 10:21 ` Marc Zyngier [this message]
2022-01-19 10:21 ` Marc Zyngier
2022-01-19 10:21 ` Marc Zyngier
2022-01-04 19:49 ` [RFC PATCH v3 05/11] KVM: arm64: Add standard hypervisor firmware register Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 06/11] KVM: arm64: Add vendor " Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 07/11] Docs: KVM: Add doc for the bitmap firmware registers Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 08/11] Docs: KVM: Rename psci.rst to hypercalls.rst Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 09/11] tools: Import ARM SMCCC definitions Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 10/11] selftests: KVM: aarch64: Introduce hypercall ABI test Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 11/11] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
2022-01-04 19:49 ` Raghavendra Rao Ananta
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=87ee5481r3.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=catalin.marinas@arm.com \
--cc=drjones@redhat.com \
--cc=james.morse@arm.com \
--cc=jasowang@redhat.com \
--cc=jingzhangos@google.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=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=pshier@google.com \
--cc=rananta@google.com \
--cc=reijiw@google.com \
--cc=ricarkol@google.com \
--cc=suzuki.poulose@arm.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.