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

[Julien Grall <julien.grall@xxxxxxx>]

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:
> > Hi,
> >
> > 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.

> Memory
> 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
> patch.
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.
Cheers,

--
Julien Grall

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