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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
