On Sun, Feb 13, 2011 at 5:08 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 02/13/2011 05:12 AM, David Gibson 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. >> > > 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/.
