On 14 October 2015 at 07:52, Pavel Fedin wrote:
> P.S. By the way, what about GICv3 data format? Are you going to
> review this part and do something with it? This would also advance
> Shlomo's work i think.
It's in my queue of things to look at at some point, but
so are a great many other thing
Hello!
> Nothing wrong with this patch, but I'd rather add it as part of
> the series which actually uses it.
Ok, as you wish, i just tried to decrease amount of out-of-tree stuff.
Additionally, i remember Andrew also wanted to do something with affinities, he
thought about adding emulation o
Hello!
> Can we have separate props for each affinity level?
Yes, we can, but i don't see any use for them in this form. Except merging
back into full MPIDR value. :)
> Are you assuming MPIDR format for this?
Yes. This is convenient because everything else (KVM, GICv3, etc) also uses
MPIDR
On Tue, Oct 13, 2015 at 10:54 AM, Peter Maydell
wrote:
> On 9 October 2015 at 10:52, Pavel Fedin wrote:
>> This allows to override default affinity IDs on a per-machine basis, and
>> possibility to retrieve IDs will be used by vGICv3 live migration code.
>>
>> Signed-off-by: Pavel Fedin
>> ---
>
On 9 October 2015 at 10:52, Pavel Fedin wrote:
> This allows to override default affinity IDs on a per-machine basis, and
> possibility to retrieve IDs will be used by vGICv3 live migration code.
>
> Signed-off-by: Pavel Fedin
> ---
> Since this popped up several times on the mailing list, i deci
This allows to override default affinity IDs on a per-machine basis, and
possibility to retrieve IDs will be used by vGICv3 live migration code.
Signed-off-by: Pavel Fedin
---
Since this popped up several times on the mailing list, i decided to publish
this early.
---
target-arm/cpu.c | 1 +
1
