From: Sean Christopherson <seanjc@google.com>
To: Michal Luczaj <mhal@rbox.co>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org, shuah@kernel.org
Subject: Re: [PATCH 2/2] KVM: selftests: Extend x86's sync_regs_test to check for races
Date: Tue, 8 Aug 2023 16:11:21 -0700 [thread overview]
Message-ID: <ZNLLmSCHL6jDa3Ie@google.com> (raw)
In-Reply-To: <5c7309cb-30be-fe99-8563-d33098adbfe9@rbox.co>
On Thu, Aug 03, 2023, Michal Luczaj wrote:
> On 8/3/23 18:41, Sean Christopherson wrote:
> > +/*
> > + * Assert that a VM or vCPU ioctl() succeeded (obviously), with extra magic to
> > + * detect if the ioctl() failed because KVM killed/bugged the VM. To detect a
> > + * dead VM, probe KVM_CAP_USER_MEMORY, which (a) has been supported by KVM
> > + * since before selftests existed and (b) should never outright fail, i.e. is
> > + * supposed to return 0 or 1. If KVM kills a VM, KVM returns -EIO for all
> > + * ioctl()s for the VM and its vCPUs, including KVM_CHECK_EXTENSION.
> > + */
>
> Do you think it's worth mentioning the ioctl() always returning -EIO in case of
> kvm->mm != current->mm? I suppose that's something purely hypothetical in this
> context.
Hmm, probably not? Practically speaking, that scenario should really only ever
happen when someone is developing a new selftest. Though I suppose a blurb in
the comment wouldn't hurt.
next prev parent reply other threads:[~2023-08-08 23:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 0:12 [PATCH 0/2] sync_regs() TOCTOU issues Michal Luczaj
2023-07-28 0:12 ` [PATCH 1/2] KVM: x86: Fix KVM_CAP_SYNC_REGS's " Michal Luczaj
2023-07-31 23:49 ` Sean Christopherson
2023-08-01 12:37 ` Michal Luczaj
2023-08-02 19:18 ` Sean Christopherson
2023-08-03 0:13 ` Michal Luczaj
2023-08-03 17:48 ` Paolo Bonzini
2023-08-03 21:15 ` Michal Luczaj
2023-08-04 9:53 ` Paolo Bonzini
2023-08-04 17:50 ` Michal Luczaj
2023-08-14 22:29 ` Michal Luczaj
2023-07-28 0:12 ` [PATCH 2/2] KVM: selftests: Extend x86's sync_regs_test to check for races Michal Luczaj
2023-08-02 21:07 ` Sean Christopherson
2023-08-03 0:44 ` Michal Luczaj
2023-08-03 16:41 ` Sean Christopherson
2023-08-03 21:14 ` Michal Luczaj
2023-08-08 23:11 ` Sean Christopherson [this message]
2023-08-02 21:11 ` [PATCH 0/2] sync_regs() TOCTOU issues Sean Christopherson
2023-08-15 0:48 ` Sean Christopherson
2023-08-15 7:37 ` Michal Luczaj
2023-08-15 15:40 ` Sean Christopherson
2023-08-15 17:49 ` Michal Luczaj
2023-08-15 18:15 ` Sean Christopherson
2023-08-15 18:38 ` Michal Luczaj
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=ZNLLmSCHL6jDa3Ie@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=mhal@rbox.co \
--cc=pbonzini@redhat.com \
--cc=shuah@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.