* Jan Kiszka <[email protected]> [2018-01-14 18:00:28 +0100]:
[...]
>
> Busy-waiting for hundreds of millisecond (however we measure them) is
> not a good thing. If that is really required, we should at least issue
> all commands to all affected functions in parallel. What is the normal
> overall time needed to complete a function reset?
>
> Measuring these periods without a time base, like we have right now, is
> challenging. We avoided introducing a time base for the hypevisor-guest
> communication protocol by letting the user specify a loop-based timeout
> per machine, to compensate the different machine speeds. Hardcoding
> loop-based timeouts is not the way to go unless you have a more or less
> known delay in the loop body (like a PCI access).
I have a staging version that goes with a new field for struct
jailhouse_pci_device:
/** A cycle-count based value that Jailhouse will wait for the device to
terminate any PCI transactions during function-level reset */
__u32 flr_timeout;
and does the same at pci.c as we got at control.com (msg_reply_timeout).
Acceptable?
[...]
> >
> > Just like the spec suggests, yes, we may abort if the devices takes
> > too long (that should not happen in first place).
>
> Abort what? Waiting for the device or even talking to it at all (i.e.
> failing it)?
Waiting for the device.
[...]
> >
> > You're right about the timing differences. What do you suggest to make
> > them more equal? Non used cap reads inside the second one? Maybe I'll
> > read the status reg inside it already.
>
> If we can derive some reliable time base from PCI accesses, that could
> do the trick.
Waiting for reception of the new approach to go forward here.
Regards,
--
Gustavo Lima Chaves
Intel - Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
