From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55792 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PoX0g-0002Gf-BM for qemu-devel@nongnu.org; Sun, 13 Feb 2011 03:08:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PoX0e-0007eW-Vt for qemu-devel@nongnu.org; Sun, 13 Feb 2011 03:08:46 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:37194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PoX0e-0007e9-R8 for qemu-devel@nongnu.org; Sun, 13 Feb 2011 03:08:44 -0500 Received: by vws12 with SMTP id 12so2485947vws.4 for ; Sun, 13 Feb 2011 00:08:44 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1297552503.14982.637.camel@pasglop> 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> From: Blue Swirl Date: Sun, 13 Feb 2011 10:08:23 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: "qemu-devel@nongnu.org List" , Paul Mackerras , Alexander Graf , anton@samba.org, David Gibson On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt wrote: > On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote: >> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt >> wrote: >> > On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote: >> >> >> >> Actually I don't quite understand the need for vty layer, why not use >> >> the chardev here directly? >> > >> > I'm not sure what you mean here... >> >> Maybe it would be reasonable to leave h_put_term_char to spapr_hcall.c >> instead of moving those to a separate file. > > Well, the VIO device instance gives the chardev instance which is all > nicely encapsulated inside spapr-vty... Also VIO devices tend to have > dedicated hcalls, not only VTY, so it makes a lot of sense to keep them > close to the rest of the VIO driver they belong to don't you think ? > > (Actually veth does, vscsi uses the more "generic" CRQ stuff which we've > added to the core VIO but you'll see that when we get those patches > ready, hopefully soon). This is a bit of a special case, much like semihosting modes for m68k or ARM, or like MOL hacks which were removed recently. From QEMU point of view, the most natural way of handling this would be hypervisor implemented in the guest side (for example BIOS). Then the hypervisor would use normal IO (or virtio) to communicate with the host. If inside QEMU, the interface of the hypervisor to the devices needs some thought. We'd like to avoid ugly interfaces like vmmouse where a device probes CPU registers directly or spaghetti interfaces like APIC. > Actually, one thing I noticed is that the current patches David posted > still have a single function with a switch/case statement for hcalls. > > I'm not 100% certain what David long term plans are here, but in our > internal "WIP" tree, we've subsequently turned that into a mechanism > where any module can call powerpc_register_hypercall() to add hcalls. > > So if David intends to move the "upstream candidate" tree in that > direction, then naturally, the calls in spapr_hcall.c are going to > disappear in favor of a pair of powerpc_register_hypercall() locally in > the vty module. Is the interface new design, or are you implementing what is used also on real HW?