From: Peter Maydell <peter.maydell@linaro.org>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] accel/kvm/kvm-all: Handle register access errors
Date: Thu, 1 Dec 2022 10:40:09 +0000 [thread overview]
Message-ID: <CAFEAcA_ORM9CpDCvPMs1XcZVhh_4fKE2wnaS_tp1s4DzZCHsXQ@mail.gmail.com> (raw)
In-Reply-To: <20221201102728.69751-1-akihiko.odaki@daynix.com>
On Thu, 1 Dec 2022 at 10:27, Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
>
> A register access error typically means something seriously wrong
> happened so that anything bad can happen after that and recovery is
> impossible.
> Even failing one register access is catastorophic as
> architecture-specific code are not written so that it torelates such
> failures.
>
> Make sure the VM stop and nothing worse happens if such an error occurs.
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
In a similar vein there was also
https://lore.kernel.org/all/20220617144857.34189-1-peterx@redhat.com/
back in June, which on the one hand was less comprehensive but on
the other does the plumbing to pass the error upwards rather than
reporting it immediately at point of failure.
I'm in principle in favour but suspect we'll run into some corner
cases where we were happily ignoring not-very-important failures
(eg if you're running Linux as the host OS on a Mac M1 and your
host kernel doesn't have this fix:
https://lore.kernel.org/all/YnHz6Cw5ONR2e+KA@google.com/T/
then QEMU will go from "works by sheer luck" to "consistently
hits this error check"). So we should aim to land this extra
error checking early in the release cycle so we have plenty of
time to deal with any bug reports we get about it.
thanks
-- PMM
next prev parent reply other threads:[~2022-12-01 10:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 10:27 [PATCH] accel/kvm/kvm-all: Handle register access errors Akihiko Odaki
2022-12-01 10:40 ` Peter Maydell [this message]
2022-12-01 11:00 ` Akihiko Odaki
2022-12-01 11:19 ` Peter Maydell
2023-06-10 3:51 ` Akihiko Odaki
2023-06-19 12:19 ` Peter Maydell
2023-09-21 7:25 ` Akihiko Odaki
2023-09-21 13:33 ` Peter Maydell
2023-09-27 10:04 ` Paolo Bonzini
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=CAFEAcA_ORM9CpDCvPMs1XcZVhh_4fKE2wnaS_tp1s4DzZCHsXQ@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=akihiko.odaki@daynix.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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).