qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [RFC PATCH 09/26] ppc/xive: add an overall memory region


From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [RFC PATCH 09/26] ppc/xive: add an overall memory region for the ESBs
Date: Mon, 24 Jul 2017 15:27:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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 <address@hidden>
>>>> ---
>>>>  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.

C.  




reply via email to

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