On Thu, 2022-11-10 at 10:24 +0100, Nico Boehr wrote: > Quoting Eric Farman (2022-11-09 21:21:56) > > From: Alexander Gordeev <agordeev@xxxxxxxxxxxxx> > > > > The ORB is a construct that is sent to the real hardware, > > so should contain a physical address in its interrupt > > parameter field. Let's clarify that. > > Maybe I don't get it, but I think the commit description is > inaccurate. The PoP > says (p. 15-25): > > > Bits 0-31 of word 0 are > > preserved unmodified in the subchannel until > > replaced by a subsequent START SUBCHANNEL or > > MODIFY SUBCHANNEL instruction. These bits are > > placed in word 1 of the interruption code when an I/O > > interruption occurs and when an interruption request > > is cleared by the execution of TEST PENDING > > INTERRUPTION. > > So the hardware actually doesn't care what kind of address this is. > Rather, the > CIO driver expects the intparam to be a physical address - probably > so it fits > 32 bits -, see do_cio_interrupt. Right, it doesn't even need to be an address; we could write 0xdeadbeef if we wanted, so long as that could be decoded by the driver on the interrupt side. I really just wanted to point out that it was sent to the channel, not that the channel (or anything else on the hardware side) used it. What about this? The ORB's interrupt parameter field is stored unmodified into the interruption code when an I/O interrupt occurs. As this reflects a real device, let's store the physical address of the subchannel struct so it can be used when processing an interrupt.
