From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH 2/2] x86/vMCE: change address space for incident reporting
Date: Mon, 28 Jun 2021 13:58:14 +0200 [thread overview]
Message-ID: <a119ae20-cd82-a4a2-e46a-38ad3cb918cf@suse.com> (raw)
In-Reply-To: <b16904ec-0302-4094-7d89-f484cbf0f8a5@suse.com>
PFNs are purely a software construct. In particular their association
with MFNs can change at any time. Switch to reporting back GFNs through
the hypercall interface (but stick to PFNs / paddr for the MSR one).
(Note that unmmap_broken_page() validly expects a GFN anyway.)
While doing the adjustments, replace an open-coded instance of
PAGE_OFFSET().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
RFC because of the change to the hypercall interface, for which the
address space is not documented anywhere anyway. Aiui the main purpose
is to get things logged, and in a (system wide, even if maintained by
Dom0) log system wide meaningful addresses are surely of more use.
--- a/xen/arch/x86/cpu/mcheck/mcaction.c
+++ b/xen/arch/x86/cpu/mcheck/mcaction.c
@@ -1,5 +1,6 @@
#include <xen/types.h>
#include <xen/sched.h>
+#include <asm/p2m.h>
#include "mcaction.h"
#include "vmce.h"
#include "mce.h"
@@ -43,7 +44,6 @@ mc_memerr_dhandler(struct mca_binfo *bin
struct mcinfo_global *global = binfo->mig;
struct domain *d;
mfn_t mfn;
- unsigned long gfn;
uint32_t status;
int vmce_vcpuid;
unsigned int mc_vcpuid;
@@ -87,11 +87,13 @@ mc_memerr_dhandler(struct mca_binfo *bin
BUG_ON( bank->mc_domid == DOMID_COW );
if ( bank->mc_domid != DOMID_XEN )
{
+ gfn_t gfn;
+
d = rcu_lock_domain_by_id(bank->mc_domid);
ASSERT(d);
- gfn = get_gpfn_from_mfn((bank->mc_addr) >> PAGE_SHIFT);
- if ( unmmap_broken_page(d, mfn, _gfn(gfn)) )
+ gfn = mfn_to_gfn(d, mfn);
+ if ( unmmap_broken_page(d, mfn, gfn) )
{
printk("Unmap broken memory %"PRI_mfn" for DOM%d failed\n",
mfn_x(mfn), d->domain_id);
@@ -115,8 +117,7 @@ mc_memerr_dhandler(struct mca_binfo *bin
else
vmce_vcpuid = mc_vcpuid;
- bank->mc_addr = gfn << PAGE_SHIFT |
- (bank->mc_addr & (PAGE_SIZE - 1));
+ bank->mc_addr = gfn_to_gaddr(gfn) | PAGE_OFFSET(bank->mc_addr);
if ( fill_vmsr_data(bank, d, global->mc_gstatus, vmce_vcpuid) )
{
mce_printk(MCE_QUIET, "Fill vMCE# data for DOM%d "
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -465,6 +465,7 @@ int fill_vmsr_data(struct mcinfo_bank *m
{
struct vcpu *v = d->vcpu[0];
bool broadcast = (vmce_vcpuid == VMCE_INJECT_BROADCAST);
+ paddr_t addr = mc_bank->mc_addr;
int ret, err;
if ( mc_bank->mc_domid == DOMID_INVALID )
@@ -479,6 +480,14 @@ int fill_vmsr_data(struct mcinfo_bank *m
}
/*
+ * Provide a PADDR through the MSR interface, for historical reasons. What
+ * we are being passed is a GADDR (i.e. MADDR for PV and PADDR for HVM).
+ */
+ if ( !paging_mode_translate(d) )
+ addr = pfn_to_paddr(get_gpfn_from_mfn(mfn_x(maddr_to_mfn(addr)))) |
+ PAGE_OFFSET(addr);
+
+ /*
* vMCE with the actual error information is injected to vCPU0,
* and, if broadcast is required, we choose to inject less severe
* vMCEs to other vCPUs. Thus guest can always get the severest
@@ -487,7 +496,7 @@ int fill_vmsr_data(struct mcinfo_bank *m
* vCPUs will not prevent guest from recovering on those vCPUs.
*/
ret = vcpu_fill_mc_msrs(v, gstatus, mc_bank->mc_status,
- mc_bank->mc_addr, mc_bank->mc_misc);
+ addr, mc_bank->mc_misc);
if ( broadcast )
for_each_vcpu ( d, v )
{
next prev parent reply other threads:[~2021-06-28 11:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 11:56 [PATCH 0/2] x86/vMCE: address handling related adjustments Jan Beulich
2021-06-28 11:57 ` [PATCH 1/2] x86/vMCE: adjustments to unmmap_broken_page() Jan Beulich
2021-06-28 11:58 ` Jan Beulich [this message]
2021-12-03 11:02 ` Ping: [PATCH 0/2] x86/vMCE: address handling related adjustments Jan Beulich
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=a119ae20-cd82-a4a2-e46a-38ad3cb918cf@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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).