All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elliott Mitchell <ehem+debian@m5p.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: 810964@bugs.debian.org, xen-devel@lists.xen.org
Subject: Re: [BUG] EDAC infomation partially missing
Date: Tue, 16 May 2017 11:02:30 -0700	[thread overview]
Message-ID: <20170516180230.GA51557@scollay.m5p.com> (raw)
In-Reply-To: <591AE87D020000780015A118@prv-mh.provo.novell.com>

On Tue, May 16, 2017 at 03:54:37AM -0600, Jan Beulich wrote:
> >>> On 16.05.17 at 05:47, <ehem+debian@m5p.com> wrote:
> >  I suspect the only paravirtualization needed is to
> > map the physical address of the soft|hard errors to which VM's memory
> > range was effected.  What this effects is which VM should panic in case
> > of hard errors.
> 
> Which in turn obviously requires hypervisor interaction. It's not really
> clear to me whether perhaps the driver would better live in the
> hypervisor in the first place for that reason.
> 
> And there's a second piece of paravirtualization needed: The driver
> doesn't distinguish physical and machine address spaces, yet the
> addresses reported by hardware are machine ones and hence would
> generally need translation to physical ones in order to assign Dom0-
> local meaning to them (or to determine that the address belongs to
> another VM or the hypervisor).

Merely reporting the machine address to Dom0 is already high value since
it lets you attribute the failure to a memory module.  Without that you
may have a VM or whole machine randomly crash for a completely unknown
reason.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         EHeM+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-05-16 18:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170513223656.GA40303@scollay.m5p.com>
2017-05-15  8:02 ` [BUG] EDAC infomation partially missing Jan Beulich
2017-05-16  3:47   ` Elliott Mitchell
2017-05-16  9:54     ` Jan Beulich
2017-05-16 10:08       ` Andrew Cooper
2017-05-16 18:02       ` Elliott Mitchell [this message]
2017-05-13 22:36 Elliott Mitchell
     [not found] <569FA160.6070308@web.de>
2016-01-21 16:41 ` Jan Beulich
2016-01-22  9:09   ` Andreas Pflug
2016-01-22 10:40     ` Jan Beulich
2016-01-22 11:33       ` Andreas Pflug
  -- strict thread matches above, loose matches on Subject: below --
2016-01-20 15:01 Andreas Pflug

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=20170516180230.GA51557@scollay.m5p.com \
    --to=ehem+debian@m5p.com \
    --cc=810964@bugs.debian.org \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.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.