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 <c...@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. >
ok. Adding that to the TODO list. C.
