Re: [Xen-devel] [PATCH v7 08/10] x86/microcode: Synchronize late microcode loading

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.06.19 at 14:36, <chao.gao@xxxxxxxxx> wrote:
> On Wed, Jun 05, 2019 at 08:09:43AM -0600, Jan Beulich wrote:
>>>>> On 27.05.19 at 10:31, <chao.gao@xxxxxxxxx> wrote:
>>On the whole, taking a 256-thread system as example, you
>>allow the whole process to take over 4 min without calling
>>panic().
>>Leaving aside guests, I don't think Xen itself would
>>survive this in all cases. We've found the need to process
>>softirqs with far smaller delays, in particular from key handlers
>>producing lots of output. At the very least there should be a
>>bold warning logged if the system had been in stop-machine
>>state for, say, longer than 100ms (value subject to discussion).
> 
> In theory, if you mean 256 cores, yes. Do you think a configurable and
> run-time changeable upper bound for the whole process can address your
> concern? The default value for this upper bound can be set to a large
> value (for example, 1s * the number of online core) and the admin can
> ajust/lower the upper bound according to the way (serial or parallel) to
> perform the update and other requirements. Once the upper bound is
> reached, we would call panic().

Well, a command line option to control the total time until
calling panic() may help, but as you've said in the past: If we
panic anyway, it doesn't matter much what the timeout is. My
point was rather to make explicit that the process may have
completed after a (too) long time. Remember you mean this
late loading to happen with guests running. We should avoid
making the system unstable as much as we can. This includes
this taking long and the completing successfully _as well as_
calling panic().

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel