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

Re: [PATCH v2 1/4] x86/guest: Introduce {get,set}_reg() infrastructure


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 19 Jan 2022 14:28:28 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zEMX9WE0p4zqIthayNM4ih2MCHjWwIm14mOVjDOi5nw=; b=hgi3C/Y9sHoXkc+uYwSSO3RBwsuTfAvdjrsIbQ24b8qF1yTfw/Qu3y4MofEhxJuZEZJYihOZzcATRluhyj545Zl8biH3cCaKj3jvkVfV/1HVvgpA9DAh1IUSDq62VUAsB8YuFs2RW0YZs1s32Le+9CQvWZg8wLH0GLM/R4VpmmlBOt9CrfFshB3bJPtMQ8bXn+j0I9r6BupIzIjtLl7rqHH+B3YisVHMQ1+2DwPVfsTEEuC/1eZi5kqNU6lo8QzJrYQ6MZMgLIkgV5rtjw8jKXS5PXbWgMrqla83FVN5mGgBzAM5yAXbiNCAj205ZIjpLbp4+4Xt0f6jfHGIF2TBIA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fqf352TyQ4vKqBbT1SbM4cwEdvpz5iDoRYLYchBoUj6TbxcZ+GAxuYtzqTlTB3S+sksXznwFo3uqU6d5S+8pOMAiZQBAcKVLVBCMBz/l6jrjRlCObX9AVMDIku4nqdjVaAlee4sCaKSV0BRYBYzWbAorj5ZvHQmfDaglymS76/PE4RbBnBD19rjQw3G79tzQt0YKsvwM6/mdMgAZXjCPwnM4725T4g6A1iY6ksaTLERKvcSviV7LYgHOWpcoKYwohHLx/7AmA7+YiCShiL+daBfwidmwRCUNkRf1V9ZkvlZspENHktcHbqpvkck81h0sc9ObCntvJm1S3N3wjsKxPw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 19 Jan 2022 13:28:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 17.01.2022 19:34, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3744,6 +3744,28 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
> msr_content,
>      return X86EMUL_EXCEPTION;
>  }
>  
> +uint64_t hvm_get_reg(struct vcpu *v, unsigned int reg)
> +{
> +    ASSERT(v == current || !vcpu_runnable(v));
> +
> +    switch ( reg )
> +    {
> +    default:
> +        return alternative_call(hvm_funcs.get_reg, v, reg);
> +    }
> +}
> +
> +void hvm_set_reg(struct vcpu *v, unsigned int reg, uint64_t val)
> +{
> +    ASSERT(v == current || !vcpu_runnable(v));
> +
> +    switch ( reg )
> +    {
> +    default:
> +        return alternative_vcall(hvm_funcs.set_reg, v, reg, val);

I'm inclined to ask to drop "return" from here.

Also, for both functions, without it being clear for what kind of
registers beyond MSRs this may want using down the road, I wonder
whether uint64_t is actually wide enough.

> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2469,6 +2469,33 @@ static bool svm_get_pending_event(struct vcpu *v, 
> struct x86_event *info)
>      return true;
>  }
>  
> +static uint64_t svm_get_reg(struct vcpu *v, unsigned int reg)
> +{
> +    struct domain *d = v->domain;
> +
> +    switch ( reg )
> +    {
> +    default:
> +        printk(XENLOG_G_ERR "%s(%pv, 0x%08x) Bad register\n",
> +               __func__, v, reg);

Is __func__ actually of much use here and in similar further places?

> @@ -852,6 +867,15 @@ static inline int hvm_vmtrace_get_option(
>      return -EOPNOTSUPP;
>  }
>  
> +static inline uint64_t pv_get_reg(struct vcpu *v, unsigned int reg)
> +{
> +    ASSERT_UNREACHABLE();
> +}
> +static inline void pv_set_reg(struct vcpu *v, unsigned int reg, uint64_t val)
> +{
> +    ASSERT_UNREACHABLE();
> +}

Were these meant to have hvm_ prefixes?

With at least this last aspect addressed
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.