On Mon, Jul 24, 2017 at 03:27:18PM +0200, Cédric Le Goater wrote:
> On 07/24/2017 08:39 AM, David Gibson wrote:
> > On Mon, Jul 24, 2017 at 04:09:31PM +1000, Benjamin Herrenschmidt wrote:
> >> On Mon, 2017-07-24 at 14:49 +1000, David Gibson wrote:
> >>> On Wed, Jul 05, 2017 at 07:13:22PM +0200, Cédric Le Goater wrote:
> >>>> Each source adds its own ESB mempry region to the overall ESB memory
> >>>> region of the controller. It will be mapped in the CPU address space
> >>>> when XIVE is activated.
> >>>>
> >>>> The default mapping address for the ESB memory region is the same one
> >>>> used on baremetal.
> >>>>
> >>>> Signed-off-by: Cédric Le Goater <c...@kaod.org>
> >>>> ---
> >>>> hw/intc/xive-internal.h | 5 +++++
> >>>> hw/intc/xive.c | 44
> >>>> +++++++++++++++++++++++++++++++++++++++++++-
> >>>> 2 files changed, 48 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/hw/intc/xive-internal.h b/hw/intc/xive-internal.h
> >>>> index 8e755aa88a14..c06be823aad0 100644
> >>>> --- a/hw/intc/xive-internal.h
> >>>> +++ b/hw/intc/xive-internal.h
> >>>> @@ -98,6 +98,7 @@ struct XIVE {
> >>>> SysBusDevice parent;
> >>>>
> >>>> /* Properties */
> >>>> + uint32_t chip_id;
> >>>
> >>> So there is a XIVE object per chip. How does this work on PAPR? One
> >>> logical chip/XIVE, or something more complex?
> >>
> >> One global XIVE for PAPR. For the MMIOs, the way it works is that:
> >>
> >> - For MMIOs pertaining to a specific interrupt or queue, there's an H-
> >> call that will return the proper "guest physical" address. For qemu
> >> with KVM we'll have to probably create a single chunk of qemu address
> >> space (a single mem region) that contains individual pages mapped with
> >> MAP_FIXED originating from the different HW bits, we still need to sort
> >> out how exactly we'll do that in practice.
> >>
> >> - For the TIMA (the presentation MMIOs), those are always at the same
> >> physical address for everybody (so for a guest it's a single memory
> >> region we'll map to that physical address), the HW "knows" which HW
> >> thread is talking to it (and the hypervisor tells the HW which vcpu is
> >> running on a given HW thread at a given point in time). That address is
> >> obtained from the device-tree
> >
> > Ok. That leaves "chip_id" as a rather surprising thing to see in an
> > object which will appear on PAPR.
>
> We could also pass the address as a property instead of the chip-id when
> creating the XIVE object. May be better for sPAPR.
Yes, I think that sounds like a much better option.
--
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
signature.asc
Description: PGP signature
