qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/7 v2] KVM regsync


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 0/7 v2] KVM regsync
Date: Thu, 24 Jan 2013 12:57:27 +0100

On 10.01.2013, at 16:28, Jason J. Herne wrote:

> Rework the method used to synchronize CPU registers between Qemu &
> KVM.  This patch set extends kvm_arch_put_registers() and
> kvm_arch_get_registers() to take a register bitmap parameter.  All
> existing code paths are updated to specify this new parameter.
> 
> IMPORTANT NOTE:  The PPC and i386 implementations are incomplete.
> I am submitting this code at this time only to get a review on the
> implementation of the existing code and to perhaps seek assistance
> with the mentioned architectures.
> 
> I am not sure who will finish the implementation of PPC/i386 yet.  Due
> to the fact that I am unfamiliar with these architectures at the
> register level and I do not have test environments I would like to
> humbly request that a maintainer of these architectures take a look at
> it.  Or perhaps Bharat could handle the PPC code?  This would only leave i386 
> to worry about.  If I cannot find someone to handle i386 I
> will look into the feasibility of completing it myself.
> 
> In order to complete the missing implementations,
> kvm_arch_get_registers and kvm_arch_put_registers (and associated
> helper functions) will need to be updated to only sync the registers
> contained in the new bitmap argument.  

I disagree. The read functions would stay the way they are, because they always 
read everything today. The write functions would read bitmap bits instead of 
"level < x". The bitmap would contain bits for

  LEVEL_1
  LEVEL_2
  LEVEL_3

with the externally used LEVEL_3 define that you would use for syncing being 
(LEVEL_1 | LEVEL_2 | LEVEL_3).

That way you keep the level based semantic and nobody really needs non-obvious 
code changes.

> Also, each set of registers
> represented  by one of the bits must be mutually exclusive with respect
> to every other bit.  if this is not the case then local register data
> can be lost when kvm_arch_get_registers is called causing an old
> register value to overwrite a newer local value.

Any get_registers call with a changing bitmap would flush out everything and 
start from scratch. Don't overoptimize from the beginning :).


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]