On 12/07/2010 01:02 PM, Alexander Graf wrote:
On 07.12.2010, at 11:59, Andre Przywara wrote:
> Newer SVM implementations provide the GPR number in the VMCB, so
> that the emulation path is no longer necesarry to handle debug
> register access intercepts. Implement the handling in svm.c and
> use it when the info is provided.
>
> Signed-off-by: Andre Przywara<andre.przywara@xxxxxxx>
> ---
> arch/x86/kvm/svm.c | 55 ++++++++++++++++++++++++++++++++++++---------------
> 1 files changed, 39 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index b7233fd..369bd85 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -2669,6 +2669,29 @@ static int cr0_write_interception(struct vcpu_svm *svm)
> return r == EMULATE_DONE;
> }
>
> +static int dr_interception(struct vcpu_svm *svm)
> +{
> + int reg, dr;
> + unsigned long val;
> +
> + if (!boot_cpu_has(SVM_FEATURE_DECODE_ASSIST))
> + return emulate_on_interception(svm);
Wouldn't it be better to just change the entry in svm_exit_handlers if we detect that feature on init? No unnecessary branching then.
I'd rather make them const instead. For something performance critical
(unlike this) we can use static_cpu_has().
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
