On Sun, Feb 13, 2011 at 1:12 PM, David Gibson <da...@gibson.dropbear.id.au> wrote: > On Sun, Feb 13, 2011 at 10:08:23AM +0200, Blue Swirl wrote: >> On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt >> <b...@kernel.crashing.org> wrote: >> > On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote: >> >> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt >> >> <b...@kernel.crashing.org> 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. > > I really don't follow what you're saying here. Running the hypervisor > in the guest, rather than emulating its effect in qemu seems like an > awful lot of complexity for no clear reason.
Maybe it would be more complex but also emulation accuracy would be increased and the interfaces would be saner. We don't shortcut BIOS and implement its services to OS in QEMU for other machines either. I'd expect one problem with that approach though, the interface used on real HW between the hypervisor and the underlying HW may be undocumented, but then it could use for example existing virtio devices. One way to handle this could be to add the hypervisor interface now to QEMU and switch to guest hypervisor when (if) it becomes available. I'd just like to avoid duplication with virtio or messy interfaces like vmport.
