Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO

[Blue Swirl]

On Sun, Feb 13, 2011 at 5:08 PM, Anthony Liguori <address@hidden> 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
>>> <address@hidden>  wrote:
>>>
>>>>
>>>> On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
>>>>
>>>>>
>>>>> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
>>>>> <address@hidden>  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/.