On 04/16/20 18:00, Nikita Leshenko wrote: > > >> On 16 Apr 2020, at 12:53, Laszlo Ersek <ler...@redhat.com> wrote: >> >> On 04/14/20 19:38, Nikita Leshenko wrote:
[...] > I break out the inner structs into separate typedefs, wrap all of them in > #pragma pack (1) / pack () and then create the wrapping aligning unions? >> (7a) either send "Req.Data" (rather than "Req") to the device in this >> function, > I wasn't aware of this padding, so I will update the code to use suggestion > (7a). OK, thanks! >> (11) Please repeat the statement from the commit message here -- as a >> code comment -- that the reply is only read to complete the doorbell >> function of the device, and that we intentionally ignore the contents. >> >> (BTW, if we do not parse the response even at the end of this series, >> then saving the response into the "Reply" variable looks useless -- I >> guess we could remove the "Reply" variable altogether, in that case. But >> I'll have to see the rest of the patches.) > We must read the reply fully to initialise the device (the device would reset > the > interrupt status only after the host has fetched the entire reply). We could > discard > the reply, but I thought it would be nicer to keep it on the stack temporary > in > case someone would like to use it in later changes or in debugging (since the > reply is very small and should be hot in the cache, I don't this has any > performance impact). Makes sense. The comment will help. Thanks! >> (12) So in general I would have suggested that, in case the >> initialization fails and we take an early "return" branch in this >> function, we should first jump to an error handling label, and reset the >> device. (Because, when we return an error code from the function, we >> shouldn't leave the device in half-initialized state.) >> >> *But*, it seems like the reset operation *itself* occurs through the >> doorbell register and the MPT_REG_ISTATUS register -- and if any step in >> MptScsiInit() fails, then it's exactly those registers that are >> (apparently) in unknown / unreliable state. In other words, if >> MptScsiInit() fails, then we *can't* (expect to) reset the device >> (successfully). >> >> Can you please confirm my understanding? (Again, just a question, not a >> code change request.) > Your understanding it correct. In VirtualBox it looks like you can't write a > reset command to the doorbell while a handshake is in progress. In any case, > wonder > what could realistically cause the initialization to fail. On EDK2 side, > we're just > talking about a bunch of "in/out" opcodes (the API for which could fail, but > I would > assume that if it fails then further "in/out"s will fail as well). On the > hypervisor > side, the QEMU and VirtualBox don't even have a failure path for the init > call. > So failure seems very theoretical here and I couldn't find anything > realistically > helpful to do if the initialization fails in the middle. Thank you for explaining. I'm proceeding with the v4 review. Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#57624): https://edk2.groups.io/g/devel/message/57624 Mute This Topic: https://groups.io/mt/73015389/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
