From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35221 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pof6I-0005u2-5T for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:47:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pof6G-0008Fm-V9 for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:47:05 -0500 Received: from mail-gw0-f45.google.com ([74.125.83.45]:65016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pof6G-0008Ff-Qn for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:47:04 -0500 Received: by gwaa12 with SMTP id a12so1920413gwa.4 for ; Sun, 13 Feb 2011 08:47:04 -0800 (PST) Message-ID: <4D580B03.6000208@codemonkey.ws> Date: Sun, 13 Feb 2011 10:46:59 -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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Blue Swirl , David Gibson , Paul Mackerras , "qemu-devel@nongnu.org List" , anton@samba.org On 02/13/2011 09:56 AM, Alexander Graf wrote: > >> 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. >> > Is there enough common ground between the hypercall interfaces that this makes sense? Between the dispatch, registration, and tracing, yes. > It sounds nice on paper, but in the end the "hypercall not implemented" return codes differ, the argument interpretation differs and even the amount of return values differ. > Yes, that's why we pass CPUState. But keep in mind, CPUState needs to be sync'd before and after the invocation. > So at the end of the day, all this interface could do is call a machine helper function to evaluate the hypercall id from its register state and dispatch to that, leaving the rest to the individual hypercall function implementation. > > The implementations themselves also couldn't be reused. A PAPR hypercall simply doesn't work on x86. PIO and MMIO interfaces make sense to share - devices implemented using them could potentially be reused later by other platforms. For the hypercall devices, that doesn't work. > Yes, which is why I'm not advocating trying to unmarshal the calls or anything like that. But the dispatch, registration, tracing, and CPU sync'ing bits can all be reused. Regards, Anthony Liguori