Re: [edk2-devel] [PATCH v4 10/13] OvmfPkg/MptScsiDxe: Initialize hardware

["Laszlo Ersek" <lersek@redhat.com>]

On 04/16/20 18:00, Nikita Leshenko wrote:
> 
> 
>> On 16 Apr 2020, at 12:53, Laszlo Ersek <lersek@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