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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

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 <clg@kaod.org>
> > 
> > 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.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]