Re: Reset problem vs. MMIO emulation, hypercalls, etc...

[David Gibson <dwg@au1.ibm.com>]

On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
> 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.

Yeah, I'd pretty much convinced myself of that by the end of
yesterday.  I hope to send patches implementing these fixes today.

There are also some questions about why our in-kernel H_CEDE works
kind of differently from x86's hlt instruction implementation (which
comes out to qemu unless the irqchip is in-kernel as well).  I don't
think we have an urgent problem there though.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson