qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Gibson
Subject: Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO
Date: Mon, 14 Feb 2011 10:30:07 +1100
User-agent: Mutt/1.5.20 (2009-06-14)

On Sun, Feb 13, 2011 at 09:08:22AM -0600, Anthony Liguori 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
[snip]
> 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.

That's correct.

> 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);

Well, I can certainly implement dynamic registration - in fact I've
done that, I just need to fold it into the earlier part of the patch
series.

But the only "address" we have for this hypercall address space is the
hypercall number, and it's not architected where that will be
supplied.  So we'd still need a per-platform hook to extract the
index from the CPUState.

> 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.
> 
> >>on real HW?
> >The interface already exists on real HW.  It's described in the PAPR
> >document we keep mentioning.
> 
> Another thing to note is that the hypercall based I/O devices the
> interfaces that the current Power hypervisor uses so implementing
> this interface is necessary to support existing guests.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson



reply via email to

[Prev in Thread] Current Thread [Next in Thread]