From: Christoph Egger <Christoph.Egger@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: p2m type change confusing emulator
Date: Tue, 3 Jul 2012 12:29:50 +0200 [thread overview]
Message-ID: <4FF2C99E.7000306@amd.com> (raw)
In-Reply-To: <4FF1CF77020000780008D1E2@nat28.tlf.novell.com>
On 07/02/12 16:42, Jan Beulich wrote:
> In a problem report for a non-Linux HVM guest with PV drivers that
> got brought to our attention, an issue in the PV driver code caused
> a XENMAPSPACE_shared_info operation to be issued in a way
> racing ongoing MMIO emulations on other vCPU-s targeting the
> gPFN being changed.
>
> The way MMIO emulation requiring callout into qemu currently works,
> handle_mmio() would be called twice for each such operation. This
> clearly assumes that both operations use consistent paths, which
> is easily violated when between the two operations the p2m type
> of the page operated on changes (in the case at hand, the
> transition was from MMIO [not handled by any device] to RAM,
> i.e. the second run through the emulator didn't even call the
> MMIO related code anymore, leaving the vCPU's io_state in
> HVMIO_completed instead of HVMIO_none, confusing the _next_
> invocation of the emulator, and obfuscating the problem quite
> significantly).
This race also affects nested virtualization where the l1 hypervisor
"forwards" its PCI devices to a guest (Hyper-V).
The race caused MMIO handling to fail because a vcpu could switch
between l2 and l1 guest between running handle_mmio() and running
the softirq. The fix was to run softirq's before switching the
guest state of the vcpu.
Christoph
> While I realize that the guest side problem makes debatable
> whether the situation really needs hypervisor improvement, I'd
> like cases like hot-added memory or devices to be considered
> here too. In particular I wonder whether emulator state
> shouldn't be preserved across the invocation of qemu, so that
> the second run through it would neither risk of looking at a
> different instruction, nor having the emulated instruction
> access other (guest) physical memory - after all, real hardware
> wouldn't decode instructions and evaluate operands more than
> once either.
>
> Thanks for any thoughts on this,
> Jan
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
prev parent reply other threads:[~2012-07-03 10:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-02 14:42 p2m type change confusing emulator Jan Beulich
2012-07-02 15:53 ` Keir Fraser
2012-07-03 10:29 ` Christoph Egger [this message]
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=4FF2C99E.7000306@amd.com \
--to=christoph.egger@amd.com \
--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.