The DBDMA engine really just reads bytes from a producing device (IDE
in our case) and shoves these bytes into memory. It doesn't care whether
any alignment takes place or not.

Our code today however assumes that block accesses always happen on
sector (512 byte) boundaries. This is a fair assumption for most cases.

However, Mac OS X really likes to do unaligned, incomplete accesses
that it finishes with the next DMA request.

So we need to read / write the unaligned bits independent of the actual
asynchronous request, because that one can only handle 512-byte-aligned
data. We also need to cache these unaligned sectors until the next DMA
request, at which point the data might be successfully flushed from the
pipe.
Signed-off-by: NAlexander Graf <agraf@suse.de>

Soon we will introduce intermediate processing pauses which will
allow the bottom half to restart a DMA request that couldn't be
fulfilled yet.

For that to work, move the processing variable into the io struct
which is what DMA providers work with.

While touching it, also change it into a bool
Signed-off-by: NAlexander Graf <agraf@suse.de>

The DBDMA controller has a bottom half to asynchronously process DMA
request queues.

This bh was stored as a gross static variable. Move it into the device
struct instead.

While at it, move all users of it to the new generic kick function.
Signed-off-by: NAlexander Graf <agraf@suse.de>

The DBDMA engine really is running all the time, waiting for input. However
we don't want to waste cycles constantly polling.

So introduce a kick function that data providers can call to notify the
DBDMA controller of new input.
Signed-off-by: NAlexander Graf <agraf@suse.de>

We usually keep struct and constant definitions in header files. Move
them there to stay consistent and to make access to fields easier.
Signed-off-by: NAlexander Graf <agraf@suse.de>

Since current_cpu is CPUState it no longer depends on CPUPPCState.

Move ppce500_set_mpic_proxy() to a new hw/ppc/ppc_e500.h because
hw/ppc/ppc.h is too heavily using CPUPPCState and PowerPCCPU.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Support in fwcfg has been around for exposure of the clock-frequency
CPU property. OpenBIOS reads it, we just never exposed it.

Since Mac OS X is very picky about its clock frequency values, let's
just take a known good value and always expose that.
Reported-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: NAlexander Graf <agraf@suse.de>

RTAS is a hypervisor provided binary blob that a guest loads and
calls into to execute certain functions.  It's similar to the
vsyscall page in Linux or the short lived VMCI paravirt interface
from VMware.

The QEMU implementation of the RTAS blob is simply a passthrough
that proxies all RTAS calls to the hypervisor via an hypercall.

While we pass a CPU argument for hypercall handling in QEMU, we
don't pass it for RTAS calls.  Since some RTAs calls require
making hypercalls (normally RTAS is implemented as guest code) we
have nasty hacks to allow that.

Add a CPU argument to RTAS call handling so we can more easily
invoke hypercalls just as guest code would.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Introduce type constant and cast macro.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Enables support for the in-kernel MPIC that thas been merged into the
KVM next branch.  This includes irqfd/KVM_IRQ_LINE support from Alex
Graf (along with some other improvements).

Note from Alex regarding kvm_irqchip_create():

  On x86, one would call kvm_irqchip_create() to initialize an
  in-kernel interrupt controller.  That function then goes ahead and
  initializes global capability variables as well as the default irq
  routing table.

  On ppc, we can't call kvm_irqchip_create() because we can have
  different types of interrupt controllers.  So we want to do all the
  things that function would do for us in the in-kernel device init
  handler.
Signed-off-by: NScott Wood <scottwood@freescale.com>
[agraf: squash in kvm_irqchip_commit_routes patch, fix non-kvm build,
        fix ppcemb]
Signed-off-by: NAlexander Graf <agraf@suse.de>

...for use by the KVM in-kernel irqchip stub.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The DMAContext is a simple pointer to an AddressSpace that is now always
already available.  Make everyone hold the address space directly,
and clean up the DMA API to use the AddressSpace directly.
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Fetch the root region from the sPAPRTCETable, and use it to build
an AddressSpace and DMAContext.

Now, everywhere we have a DMAContext we also have access to the
corresponding AddressSpace (either because we create it just before
the DMAContext, or because dma_context_memory's AddressSpace is
trivially address_space_memory).
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Now we can stop using a "translating" DMAContext, but we do not yet modify
the sPAPRTCETable users to get an AddressSpace; they keep using the table
via a DMAContext.
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The TCE table is currently returned as a DMAContext, and non-type-safe
APIs are called later passing back the DMAContext.  Since we want to move
away from DMAContext, use an opaque type instead, and add an accessor
to retrieve the DMAContext from it.
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it necessary to compile these files per-target.
However, fixing this does not belong in these patches.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>