[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