qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v2 09/21] ppc/xive: extend the interrupt pre


From: Cédric Le Goater
Subject: Re: [Qemu-devel] [RFC PATCH v2 09/21] ppc/xive: extend the interrupt presenter model for XIVE
Date: Fri, 22 Sep 2017 14:27:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 09/22/2017 12:58 PM, David Gibson wrote:
> On Tue, Sep 19, 2017 at 09:28:45PM +0200, Cédric Le Goater wrote:
>> On 09/19/2017 09:36 AM, David Gibson wrote:
>>> On Mon, Sep 11, 2017 at 07:12:23PM +0200, Cédric Le Goater wrote:
>>>> The XIVE interrupt presenter exposes a set of Thread Interrupt
>>>> Management Areas, also called rings, one per different level of
>>>> privilege (four in all). This area is used to handle priority
>>>> management and interrupt acknowledgment among other things.
>>>>
>>>> We extend the ICPState object with a cache of the register data for
>>>> XIVE. The integration with the sPAPR machine is much easier and we
>>>> need a common framework to switch from one controller model to
>>>> another: XICS <-> XIVE.
>>>
>>> This sounds like an even worse idea than referencing the ICS state.
>>
>> ok ok.
>>
>>> The TIMA really needs to be managed by a different object than the ICP.
>>
>> like an array under the machine indexed by the cpu index ? 
> 
> Or individual TIMA objects which the cpus point to using their intc
> pointers.

ah ok. We really are splitting the two worlds.

C.
 
>> at some point, we will need to :
>>
>>     PowerPCCPU *cpu = POWERPC_CPU(current_cpu);
>>     ICPState *icp = ICP(cpu->intc);
>>
>> and 
>>
>>     icp = xics_icp_get(xive->ics->xics, target);
>>
>>
>> isn't the cpu->intc pointer  the best option to hold that information ? 
>> and it is migrated.
> 
> No, it shouldn't be migrated.  It's set up during machine construction.
> 




reply via email to

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