From: Sean Christopherson <seanjc@google.com>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: Jim Mattson <jmattson@google.com>,
kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
Marc Zyngier <maz@kernel.org>, Peter Shier <pshier@google.com>,
linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvmarm@lists.cs.columbia.edu,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start
Date: Fri, 14 Jan 2022 01:10:03 +0000 [thread overview]
Message-ID: <YeDNa+/rF0YEVJAi@google.com> (raw)
In-Reply-To: <CAJHc60wRrgnvwqPWdXdvoqT0V9isXW5xH=btgdjPWQkqVW31Pw@mail.gmail.com>
On Thu, Jan 13, 2022, Raghavendra Rao Ananta wrote:
> On Thu, Jan 13, 2022 at 9:21 AM Sean Christopherson <seanjc@google.com> wrote:
> > If restricting updates in the arm64 is necessary to ensure KVM provides sane
> > behavior, then it could be justified. But if it's purely a sanity check on
> > behalf of the guest, then it's not justified.
> Agreed that KVM doesn't really safeguard the guests, but just curious,
> is there really a downside in adding this thin layer of safety check?
It's more stuff that KVM has to maintain, creates an ABI that KVM must adhere to,
potentially creates inconsistencies in KVM, and prevents using KVM to intentionally
do stupid things to test scenarios that are "impossible". And we also try to avoid
defining arbitrary CPU behavior in KVM (that may not be the case here).
> On the bright side, the guests would be safe, and it could save the
> developers some time in hunting down the bugs in this path, no?
Yes, but that can be said for lots and lots of things. This is both a slippery
slope argument and the inconsistency argument above, e.g. if KVM actively prevents
userspace from doing X, why doesn't KVM prevent userspace from doing Y? Having a
decently defined rule for these types of things, e.g. protect KVM/kernel and adhere
to the architecture but otherwise let userspace do whatever, avoids spending too
much time arguing over what KVM should/shouldn't allow, or wondering why on earth
KVM does XYZ, at least in theory :-)
There are certainly times where KVM could have saved userspace some pain, but
overall I do think KVM is better off staying out of the way when 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-14 1:11 UTC|newest]
Thread overview: 51+ 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 ` [RFC PATCH v3 01/11] KVM: Capture VM start Raghavendra Rao Ananta
2022-01-07 6:06 ` Reiji Watanabe
2022-01-07 23:43 ` Raghavendra Rao Ananta
2022-01-08 0:04 ` Jim Mattson
2022-01-10 23:07 ` Raghavendra Rao Ananta
2022-01-10 23:57 ` Jim Mattson
2022-01-11 18:52 ` Raghavendra Rao Ananta
2022-01-11 19:16 ` Jim Mattson
2022-01-12 18:29 ` Raghavendra Rao Ananta
2022-01-13 17:21 ` Sean Christopherson
2022-01-14 0:42 ` Raghavendra Rao Ananta
2022-01-14 1:10 ` Sean Christopherson [this message]
2022-01-14 21:51 ` Reiji Watanabe
2022-01-18 22:54 ` Raghavendra Rao Ananta
2022-01-19 0:07 ` Sean Christopherson
2022-01-19 7:47 ` Reiji Watanabe
2022-01-20 0:27 ` Sean Christopherson
2022-01-20 19:16 ` Raghavendra Rao Ananta
2022-01-25 15:15 ` Marc Zyngier
2022-01-25 15:10 ` Marc Zyngier
2022-01-11 0:03 ` Reiji Watanabe
2022-01-11 18:54 ` Raghavendra Rao Ananta
2022-01-08 1:06 ` Sean Christopherson
2022-01-10 23:23 ` Raghavendra Rao Ananta
2022-01-11 17:36 ` Sean Christopherson
2022-01-11 18:46 ` Raghavendra Rao Ananta
2022-01-11 19:04 ` Sean Christopherson
2022-01-12 18:08 ` Raghavendra Rao Ananta
2022-01-12 18:24 ` 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 ` [RFC PATCH v3 03/11] KVM: Introduce KVM_CAP_ARM_HVC_FW_REG_BMAP Raghavendra Rao Ananta
2022-01-08 5:40 ` Reiji Watanabe
2022-01-10 23:40 ` Raghavendra Rao Ananta
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-10 6:28 ` Reiji Watanabe
2022-01-11 0:50 ` Raghavendra Rao Ananta
2022-01-12 5:11 ` Reiji Watanabe
2022-01-12 18:02 ` Raghavendra Rao Ananta
2022-01-14 6:23 ` Reiji Watanabe
2022-01-19 6:42 ` Jason Wang
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 ` [RFC PATCH v3 06/11] KVM: arm64: Add vendor " 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 ` [RFC PATCH v3 08/11] Docs: KVM: Rename psci.rst to hypercalls.rst 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 ` [RFC PATCH v3 10/11] selftests: KVM: aarch64: Introduce hypercall ABI test 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
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=YeDNa+/rF0YEVJAi@google.com \
--to=seanjc@google.com \
--cc=catalin.marinas@arm.com \
--cc=jmattson@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=maz@kernel.org \
--cc=pbonzini@redhat.com \
--cc=pshier@google.com \
--cc=rananta@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).