[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On 10/05/18 15:12, Mirela Simonovic wrote:
Hi Julien,

On Thu, May 10, 2018 at 3:29 PM, Julien Grall <julien.grall@xxxxxxx> wrote:

On 05/10/2018 02:24 PM, Mirela Simonovic wrote:

On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic
<mirela.simonovic@xxxxxxxxxx> wrote:

I have tested the tuned scenario where enabling capabilities fails -
the erroneous CPU is stopped/powered down and the system continues to
work fine without it. Although I still don't understand why indeed I
needed to debug this I'll add the fix in v4.

I don't understand your last sentence. What did you mean?

I still don't understand how can this scenario happen practically at
runtime (a scenario without me tuning the failure for testing).

error path are by nature hard to reach without tweaking the code. Imagine something that can only happen once every thousand boot. It is not often, but thanks to murphy that will only happen at the worst moment. And you know very well how it is a pain to debug :).

So I always tend to tweak the code in order to exercise major error path.

allocation failure shouldn't be possible at this point and any
workaround related failure would have happened at boot.
I don't see
anything else or my understanding may not be correct...
However, if some new capability would be introduced one day and it
could fail, it would be good if we don't have to go back and fix this

The memory failure was an example among the other. The whole point here is you can't extrapolate how the errata are implemented today for future one. I also want to limit the number of stop_cpu/panic over the code, so we have only place to make the decision if something is wrong.

At the end, it doesn't matter since the system will be able to
properly deal with such a scenario with the fix.

I would be ok having stop_cpu called here. Although my preference is returning an error and let the caller decides what to do.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.