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