From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Gibson <dwg@au1.ibm.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Avi Kivity <avi@redhat.com>,
kvm@vger.kernel.org, Alexander Graf <agraf@suse.de>,
Paul Mackerras <paulus@au1.ibm.com>,
kvm-ppc@vger.kernel.org
Subject: Re: Reset problem vs. MMIO emulation, hypercalls, etc...
Date: Tue, 07 Aug 2012 06:57:57 +1000 [thread overview]
Message-ID: <1344286677.24037.100.camel@pasglop> (raw)
In-Reply-To: <20120806031344.GG16664@truffala.fritz.box>
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
> So, I'm still trying to nut out the implications for H_CEDE, and think
> if there are any other hypercalls that might want to block the guest
> for a time. We were considering blocking H_PUT_TCE if qemu devices
> had active dma maps on the previously mapped iovas. I'm not sure if
> the discussions that led to the inclusion of the qemu IOMMU code
> decided that was wholly unnnecessary or just not necessary for the
> time being.
For "sleeping hcalls" they will simply have to set exit_request to
complete the hcall from the kernel perspective, leaving us in a state
where the kernel is about to restart at srr0 + 4, along with some other
flag (stop or halt) to actually freeze the vcpu.
If such an "async" hcall decides to return an error, it can then set
gpr3 directly using ioctls before restarting the vcpu.
Cheers,
Ben.
next prev parent reply other threads:[~2012-08-06 20:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 3:17 Reset problem vs. MMIO emulation, hypercalls, etc Benjamin Herrenschmidt
2012-08-02 10:46 ` Alexander Graf
2012-08-02 12:22 ` Benjamin Herrenschmidt
2012-08-02 12:35 ` Avi Kivity
2012-08-02 12:59 ` Alexander Graf
2012-08-02 13:05 ` Avi Kivity
2012-08-02 20:29 ` Benjamin Herrenschmidt
2012-08-05 8:55 ` Avi Kivity
2012-08-05 20:45 ` Benjamin Herrenschmidt
2012-08-02 20:20 ` Benjamin Herrenschmidt
2012-08-03 17:41 ` Marcelo Tosatti
2012-08-03 18:05 ` Marcelo Tosatti
2012-08-03 22:32 ` Benjamin Herrenschmidt
2012-08-05 9:00 ` Avi Kivity
2012-08-06 20:25 ` Scott Wood
2012-08-07 8:44 ` Avi Kivity
2012-08-06 20:54 ` Benjamin Herrenschmidt
2012-08-03 22:30 ` Benjamin Herrenschmidt
2012-08-06 3:13 ` David Gibson
2012-08-06 20:57 ` Benjamin Herrenschmidt [this message]
2012-08-07 1:32 ` David Gibson
2012-08-07 8:46 ` Avi Kivity
2012-08-07 12:14 ` David Gibson
2012-08-07 13:13 ` Avi Kivity
2012-08-07 21:09 ` Benjamin Herrenschmidt
2012-08-08 8:52 ` Avi Kivity
2012-08-08 9:27 ` Benjamin Herrenschmidt
2012-08-08 0:49 ` David Gibson
2012-08-08 8:58 ` Avi Kivity
2012-08-08 11:59 ` David Gibson
2012-08-08 12:42 ` Avi Kivity
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=1344286677.24037.100.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=dwg@au1.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=paulus@au1.ibm.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 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).