On 5 March 2014 15:01, alvise rigo wrote:
> So, if the processor does not start in AArch64 mode, we only add the AArch32
> version of the ARM_CP_STATE_BOTH register to the hashtable, otherwise
> nothing changes and we add the two views of the register.
Yes, I think if we want TCG<->KVM migration
Indeed, this is one of the problem I workaround with the patch.
One not much intrusive solution that I see now is to decouple the AArch64
definitions from AArch32. For example we can make add_cpreg_to_hashtable()
aware of the processor architecture with something like:
diff --git a/target-arm/help
On 26 February 2014 10:02, alvise rigo wrote:
> I agree that this is a sort of workaround, but it seems to me that a
> proper solution is not possible without changing the ideas contemplated
> now in the migration code.
> Are we willing to accept some major changes in the code to embrace
> this ty
On 26 February 2014 10:27, alvise rigo wrote:
> Improvements of cpreg emulation apart, we will still need to tackle
> with the great amount of registers not migrated because generated
> by a wildcarded register; some of these registers are in fact migrated
> by KVM. I think that the idea of keepin
Improvements of cpreg emulation apart, we will still need to tackle
with the great amount of registers not migrated because generated
by a wildcarded register; some of these registers are in fact migrated
by KVM. I think that the idea of keeping a reference
to the generator register (i.e. the only
On 26 February 2014 10:02, alvise rigo wrote:
> I agree that this is a sort of workaround, but it seems to me that a
> proper solution is not possible without changing the ideas contemplated
> now in the migration code.
> Are we willing to accept some major changes in the code to embrace
> this ty
I agree that this is a sort of workaround, but it seems to me that a
proper solution is not possible without changing the ideas contemplated
now in the migration code.
Are we willing to accept some major changes in the code to embrace
this type of migration?
Thanks,
alvise
On Tue, Feb 25, 2014 a
On 25 February 2014 16:52, Alvise Rigo wrote:
> CPUARMState:
> * added adfsr cp register.
> * added aifsr cp register.
> These registers have been added because they are migrated by KVM. This
> prevents
> the migration from failing when trying to copy their values.
This should be done in a separ
CPUARMState:
* added adfsr cp register.
* added aifsr cp register.
These registers have been added because they are migrated by KVM. This prevents
the migration from failing when trying to copy their values.
ARMCPRegInfo:
* added a pointer to the parent that generated the register (if any).
* a fl
