| Message ID | 1393347170-28502-3-git-send-email-a.rigo@virtualopensystems.com |
|---|---|
| State | New |
| Headers | show |
On 25 February 2014 16:52, Alvise Rigo <a.rigo@virtualopensystems.com> wrote: > The value of this flag indicates the execution mode of the CPU prior the > migration. It is used to handle the KVM <-> TCG migration. > > Signed-off-by: Alvise Rigo <a.rigo@virtualopensystems.com> > --- > target-arm/cpu-qom.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h > index afbd422..6819bfc 100644 > --- a/target-arm/cpu-qom.h > +++ b/target-arm/cpu-qom.h > @@ -102,6 +102,9 @@ typedef struct ARMCPU { > */ > uint32_t kvm_target; > > + /* true if this cpu is using KVM. Read and set in cpu_pre/post_load */ > + bool running_kvm; This is definitely wrong. We should not care whether either end of the migration connection is using KVM. thanks -- PMM
I see, but how can we know the type of migration (KVM to TCG or TCG to KVM) which is taking place only looking at the incoming data? Of course, I'm supposing that the two cases will require different handling and so that distinguish the migration type (at the destination) has to be part of the process. thanks, alvise On Tue, Feb 25, 2014 at 7:19 PM, Peter Maydell <peter.maydell@linaro.org>wrote: > On 25 February 2014 16:52, Alvise Rigo <a.rigo@virtualopensystems.com> > wrote: > > The value of this flag indicates the execution mode of the CPU prior the > > migration. It is used to handle the KVM <-> TCG migration. > > > > Signed-off-by: Alvise Rigo <a.rigo@virtualopensystems.com> > > --- > > target-arm/cpu-qom.h | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h > > index afbd422..6819bfc 100644 > > --- a/target-arm/cpu-qom.h > > +++ b/target-arm/cpu-qom.h > > @@ -102,6 +102,9 @@ typedef struct ARMCPU { > > */ > > uint32_t kvm_target; > > > > + /* true if this cpu is using KVM. Read and set in cpu_pre/post_load > */ > > + bool running_kvm; > > This is definitely wrong. We should not care whether either > end of the migration connection is using KVM. > > thanks > -- PMM >
On 26 February 2014 09:16, alvise rigo <a.rigo@virtualopensystems.com> wrote: > I see, but how can we know the type of migration (KVM to TCG or TCG to > KVM) which is taking place only looking at the incoming data? Of course, > I'm supposing that the two cases will require different handling and so > that distinguish the migration type (at the destination) has to be part > of the process. That's my point -- the two cases should not require different handling: you should just handle the migration and succeed if possible or fail if not, based on the incnoming data alone. thanks -- PMM
diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h index afbd422..6819bfc 100644 --- a/target-arm/cpu-qom.h +++ b/target-arm/cpu-qom.h @@ -102,6 +102,9 @@ typedef struct ARMCPU { */ uint32_t kvm_target; + /* true if this cpu is using KVM. Read and set in cpu_pre/post_load */ + bool running_kvm; + /* The instance init functions for implementation-specific subclasses * set these fields to specify the implementation-dependent values of * various constant registers and reset values of non-constant
The value of this flag indicates the execution mode of the CPU prior the migration. It is used to handle the KVM <-> TCG migration. Signed-off-by: Alvise Rigo <a.rigo@virtualopensystems.com> --- target-arm/cpu-qom.h | 3 +++ 1 file changed, 3 insertions(+)