Re: [Qemu-devel] [PATCH v7 03/19] ppc/xive: introduce a simplified XIVE presenter

[Cédric Le Goater]

On 12/11/18 2:37 AM, David Gibson wrote:
> On Mon, Dec 10, 2018 at 08:15:40AM +0100, Cédric Le Goater wrote:
>> On 12/10/18 5:27 AM, David Gibson wrote:
>>> On Sun, Dec 09, 2018 at 08:45:54PM +0100, Cédric Le Goater wrote:
>>>> The last sub-engine of the XIVE architecture is the Interrupt
>>>> Virtualization Presentation Engine (IVPE). On HW, the IVRE and the
>>>> IVPE share elements, the Power Bus interface (CQ), the routing table
>>>> descriptors, and they can be combined in the same HW logic. We do the
>>>> same in QEMU and combine both engines in the XiveRouter for
>>>> simplicity.
>>>>
>>>> When the IVRE has completed its job of matching an event source with a
>>>> Notification Virtual Target (NVT) to notify, it forwards the event
>>>> notification to the IVPE sub-engine. The IVPE scans the thread
>>>> interrupt contexts of the Notification Virtual Targets (NVT)
>>>> dispatched on the HW processor threads and if a match is found, it
>>>> signals the thread. If not, the IVPE escalates the notification to
>>>> some other targets and records the notification in a backlog queue.
>>>>
>>>> The IVPE maintains the thread interrupt context state for each of its
>>>> NVTs not dispatched on HW processor threads in the Notification
>>>> Virtual Target table (NVTT).
>>>>
>>>> The model currently only supports single NVT notifications.
>>>>
>>>> Signed-off-by: Cédric Le Goater <address@hidden>
>>>
>>> Applied.
>>>
>>> I think the tctx_word2() should have the byteswap, rather than having
>>> it in the callers, but that can be fixed later.
>>
>> I thought it was better to explicitly show in the code where the 
>> byteswaps were needed. Anyway, this is very localized, so, yes, 
>> we can change it later on.
> 
> To clarify my thinking here; the important thing is not knowing where
> the byteswaps are, but being able to tell as easily as possible what
> endianness a given piece of data is right now.
> 
> The convention I'm aiming for here - which is one I try to use most
> places is that structures - at least structures which map to specific
> in-memory things - are in the required endianness for that stuff in
> memory.  However bare integers - uint32_t or uint64_t or whatever -
> are, well, numbers, in native endian.
> 

ok. Adding that to the TODO list.

C.