From: Aili Yao <firstname.lastname@example.org>
To: Borislav Petkov <email@example.com>
Cc: <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>,
<email@example.com>, <firstname.lastname@example.org>, <email@example.com>,
Subject: Re: [PATCH v2] x86/mce: fix wrong no-return-ip logic in do_machine_check()
Date: Tue, 23 Feb 2021 10:27:55 +0800 [thread overview]
Message-ID: <20210223102755.13cbdffd@alex-virtual-machine> (raw)
On Mon, 22 Feb 2021 13:45:50 +0100
Borislav Petkov <firstname.lastname@example.org> wrote:
> On Mon, Feb 22, 2021 at 08:35:49PM +0800, Aili Yao wrote:
> > Guest VM, the qemu has no way to know the RIPV value, so always get it
> > cleared.
> What does that mean?
> The guest VM will get the MCE signature it gets from the host kernel so
> the host kernel most definitely knows the RIPV value.
When Guest access one address with UE error, it will exit guest mode, the host
will do the recovery job, and then one SIGBUS is send to the VCPU and qemu will
catch the signal, there is only address and error level no RIPV in signal, so qemu will
assume RIPV is cleared and inject the error into guest OS.
> It looks like you're testing how guests will handle MCEs which the host
> has caught and wants to inject into the guest for further handling. What
> is your exact use case? Please explain in detail how I can reproduce it
> step-by-step locally.
Yeah, there are multiple steps i do:
1. One small test code in guest OS access one address A which will be injected UC error,
the address will be logged, and use vtop you can get the guest physical address.
2. Using "virsh qemu-monitor-command guest --hmp gpa2hvagpa2hva 0xxxxxx" to get the user
3. Using vtop you can get host physical address from the above user address.
4. Inject 0x10 level error using einj module.
5. then when guest access the address, you will see what happens.
Please using latest upstream kernel for guest OS, and you may change monarch_timeout to a bigger
value, or you will see other issues not only talked one.
next prev parent reply other threads:[~2021-02-23 2:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-22 3:31 x86/mce: fix wrong no-return-ip logic in do_machine_check() Aili Yao
2021-02-22 3:50 ` [PATCH v2] " Aili Yao
2021-02-22 9:24 ` Borislav Petkov
2021-02-22 9:31 ` Aili Yao
2021-02-22 10:03 ` Borislav Petkov
2021-02-22 10:08 ` Aili Yao
2021-02-22 10:22 ` Borislav Petkov
2021-02-22 11:21 ` Aili Yao
2021-02-22 12:17 ` Aili Yao
2021-02-22 12:22 ` Borislav Petkov
2021-02-22 12:35 ` Aili Yao
2021-02-22 12:45 ` Borislav Petkov
2021-02-23 2:27 ` Aili Yao [this message]
2021-02-23 9:43 ` Borislav Petkov
2021-02-23 9:56 ` Aili Yao
2021-02-23 10:05 ` Borislav Petkov
2021-02-23 11:27 ` Aili Yao
2021-02-23 16:12 ` Luck, Tony
2021-02-24 2:39 ` Aili Yao
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).