All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: kvm@vger.kernel.org, Suzuki K Poulose <Suzuki.Poulose@arm.com>,
	Steven Price <steven.price@arm.com>,
	Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: Re: [PATCH kvmtool 1/2] cpu: vmexit: Handle KVM_EXIT_UNKNOWN exit reason correctly
Date: Tue, 11 Feb 2025 22:34:23 +0530	[thread overview]
Message-ID: <yq5ao6z8wgyw.fsf@kernel.org> (raw)
In-Reply-To: <Z6s+s4hCZwoR8uod@arm.com>

Alexandru Elisei <alexandru.elisei@arm.com> writes:

> Hi,
>
> On Tue, Feb 11, 2025 at 01:08:51PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> The return value for the KVM_RUN ioctl is confusing and has led to
>> errors in different kernel exit handlers. A return value of 0 indicates
>> a return to the VMM, whereas a return value of 1 indicates resuming
>> execution in the guest. Some handlers mistakenly return 0 to force a
>> return to the guest.
>
> I find this paragraph confusing. KVM_RUN, as per the documentation, returns 0 or
> -1 (on error). As far as I can tell, at least on arm64, KVM_RUN can never return
> 1.
>
> Are you referring to the loop in kvm_arch_vcpu_ioctl_run() by any chance? That's
> the only place I found where a value of 1 from the handlers signifies return to
> the guest.
>

Yes. I will update the commit message to reflect that. It is the exit
handler return value rather than KVM_RUN ioctl return value.

>
>> 
>> This worked in kvmtool because the exit_reason defaulted to
>> 0 (KVM_EXIT_UNKNOWN), and kvmtool did not error out on an unknown exit
>> reason. However, forcing a KVM panic on an unknown exit reason would
>> help catch these bugs early.
>
> I would hope that a VMM cannot force KVM to panic at will, which will bring down
> the host. Are you referring to kvmtool exiting with an error? That's what the
> unfortunately named 'panic_kvm' label seems to be doing.
>

yes. I will update the commit message to indicate that for
KVM_EXIT_UNKNOWN exit reason, kvmtool will now exit with an error
instead of returning to the guest."

-aneesh

      reply	other threads:[~2025-02-11 17:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-11  7:38 [PATCH kvmtool 1/2] cpu: vmexit: Handle KVM_EXIT_UNKNOWN exit reason correctly Aneesh Kumar K.V (Arm)
2025-02-11  7:38 ` [PATCH kvmtool 2/2] cpu: vmexit: Handle KVM_EXIT_MEMORY_FAULT correctly Aneesh Kumar K.V (Arm)
2025-02-11 11:48   ` Will Deacon
2025-02-11 16:56     ` Aneesh Kumar K.V
2025-02-11 12:13   ` Alexandru Elisei
2025-02-11 16:51     ` Aneesh Kumar K.V
2025-02-11 11:47 ` [PATCH kvmtool 1/2] cpu: vmexit: Handle KVM_EXIT_UNKNOWN exit reason correctly Will Deacon
2025-02-11 16:58   ` Aneesh Kumar K.V
2025-02-11 12:12 ` Alexandru Elisei
2025-02-11 17:04   ` Aneesh Kumar K.V [this message]

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=yq5ao6z8wgyw.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=Suzuki.Poulose@arm.com \
    --cc=alexandru.elisei@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=steven.price@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.