All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Huang Ying <ying.huang@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH] QEMU-KVM: MCE: Relay UCR MCE to guest
Date: Tue, 08 Sep 2009 09:44:40 +0300	[thread overview]
Message-ID: <4AA5FD58.3020506@redhat.com> (raw)
In-Reply-To: <1252312353.14648.731.camel@yhuang-dev.sh.intel.com>

On 09/07/2009 11:32 AM, Huang Ying wrote:
> UCR (uncorrected recovery) MCE is supported in recent Intel CPUs,
> where some hardware error such as some memory error can be reported
> without PCC (processor context corrupted). To recover from such MCE,
> the corresponding memory will be unmapped, and all processes accessing
> the memory will be killed via SIGBUS.
>
> For KVM, if QEMU/KVM is killed, all guest processes will be killed
> too. So we relay SIGBUS from host OS to guest system via a UCR MCE
> injection. Then guest OS can isolate corresponding memory and kill
> necessary guest processes only. SIGBUS sent to main thread (not VCPU
> threads) will be broadcast to all VCPU threads as UCR MCE.
>
>    

Won't the guest be confused by the broadcast?  How does real hardware work?
>
> +static void sigbus_handler(int n, struct signalfd_siginfo *siginfo, void *ctx)
> +{
> +    if (siginfo->ssi_code == BUS_MCEERR_AO) {
> +        uint64_t status;
> +        unsigned long paddr;
> +        CPUState *cenv;
> +
> +        /* Hope we are lucky for AO MCE */
> +        if (kvm_addr_userspace_to_phys((unsigned long)siginfo->ssi_addr,
> +&paddr)) {
> +            fprintf(stderr, "Hardware memory error for memory used by "
> +                    "QEMU itself instead of guest system!: %llx\n",
> +                    (unsigned long long)siginfo->ssi_addr);
> +            return;
> +        }
> +        status = MCI_STATUS_VAL | MCI_STATUS_UC | MCI_STATUS_EN
> +            | MCI_STATUS_MISCV | MCI_STATUS_ADDRV | MCI_STATUS_S
> +            | 0xc0;
> +        kvm_inject_x86_mce(first_cpu, 9, status,
> +                           MCG_STATUS_MCIP | MCG_STATUS_RIPV, paddr,
> +                           (MCM_ADDR_PHYS<<  6) | 0xc);
>    

This is a vcpu ioctl, yes?  if so it must be called from the vcpu thread.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


  parent reply	other threads:[~2009-09-08  6:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-07  8:32 [PATCH] QEMU-KVM: MCE: Relay UCR MCE to guest Huang Ying
2009-09-07 20:48 ` Anthony Liguori
2009-09-08  5:41   ` Huang Ying
2009-09-08 13:07     ` Anthony Liguori
2009-09-08  6:41   ` Avi Kivity
2009-09-08  6:46     ` Huang Ying
2009-09-08  8:11   ` Andi Kleen
2009-09-09 12:10     ` Avi Kivity
2009-09-10  2:50       ` Huang Ying
2009-09-08  6:44 ` Avi Kivity [this message]
2009-09-08  6:43   ` Huang Ying

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=4AA5FD58.3020506@redhat.com \
    --to=avi@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=kvm@vger.kernel.org \
    --cc=ying.huang@intel.com \
    /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.