From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42703 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PohgO-0004A2-5j for qemu-devel@nongnu.org; Sun, 13 Feb 2011 14:32:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PohgM-0000KG-BN for qemu-devel@nongnu.org; Sun, 13 Feb 2011 14:32:31 -0500 Received: from mail-gy0-f173.google.com ([209.85.160.173]:43745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PohgM-0000K3-0q for qemu-devel@nongnu.org; Sun, 13 Feb 2011 14:32:30 -0500 Received: by gye5 with SMTP id 5so1958174gye.4 for ; Sun, 13 Feb 2011 11:32:29 -0800 (PST) Message-ID: <4D5831C7.2010200@codemonkey.ws> Date: Sun, 13 Feb 2011 13:32:23 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO References: <1297522467-5975-1-git-send-email-david@gibson.dropbear.id.au> <1297522467-5975-16-git-send-email-david@gibson.dropbear.id.au> <1BA55C28-0AAF-46A5-A14F-04B0B61419DB@suse.de> <1297544424.14982.628.camel@pasglop> <1297552503.14982.637.camel@pasglop> <20110213111245.GC18294@yookeroo> <4D57F3E6.10504@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: David Gibson , Paul Mackerras , Alexander Graf , anton@samba.org, "qemu-devel@nongnu.org List" On 02/13/2011 12:29 PM, Blue Swirl wrote: > On Sun, Feb 13, 2011 at 5:08 PM, Anthony Liguori wrote: > >> >> In KVM for x86, instead of using a secondary interface (like >> vmmcall/vmcall), we do all of our paravirtualization using native hardware >> interfaces that we can trap (PIO/MMIO). >> >> IIUC, on Power, trapping MMIO is not possible due to the MMU mode that is >> currently used (PFs are delivered directly to the guest). >> >> So it's not really possible to switch from using hypercalls to using MMIO. >> >> What I would suggest is modelling hypercalls as another I/O address space >> for the processor. So instead of having a function pointer in the CPUState, >> introduce a: >> >> typedef void (HypercallFunc)(CPUState *env, void *opaque); >> >> /* register a hypercall handler */ >> void register_hypercall(target_ulong index, HypercallFunc *handler, void >> *opaque); >> void unregister_hypercall(target_ulong index); >> >> /* dispatch a hypercall */ >> void cpu_hypercall(CPUState *env, target_ulong index); >> >> This interface could also be used to implement hypercall based interfaces on >> s390 and x86. >> >> The arguments will have to be extracted from the CPU state but I don't think >> we'll really ever have common hypercall implementations anyway so that's not >> a huge problem. >> > Nice idea. Then the part handling CPUState probably should belong to > target-ppc/ rather than hw/. > Would be nice to have the target-ppc/ hypercall handlers call into a higher level VIO interface that didn't deal directly with CPUState. The actual hardware emulation would then be implemented in hw/ and would not be compiled for a specific target. That helps avoid future sloppiness. Regards, Anthony Liguori