xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH RFC v2] pvh: clearly specify used parameters in vcpu_guest_context
Date: Tue, 19 Nov 2013 10:34:11 +0000	[thread overview]
Message-ID: <528B3EA3.9090008@eu.citrix.com> (raw)
In-Reply-To: <1384798711-4255-1-git-send-email-roger.pau@citrix.com>

On 11/18/2013 06:18 PM, Roger Pau Monne wrote:
> The aim of this patch is to define a stable way in which PVH is
> going to do AP bringup.
>
> Since we are running inside of a HVM container, PVH should only need
> to set flags, cr3 and user_regs in order to bring up a vCPU, the rest
> can be set once the vCPU is started using the bare metal methods.
> Additionally, the guest can also set cr0 and cr4, and those values
> will be appended to the default values set by Xen.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Keir Fraser <keir@xen.org>
> ---
>   xen/arch/x86/domain.c             |   24 ++++++++++++++++--------
>   xen/arch/x86/hvm/vmx/vmx.c        |    6 +-----
>   xen/include/asm-x86/hvm/hvm.h     |    6 +++---
>   xen/include/public/arch-x86/xen.h |    8 ++++----
>   4 files changed, 24 insertions(+), 20 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index a3868f9..51311fc 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -51,6 +51,7 @@
>   #include <asm/fixmap.h>
>   #include <asm/hvm/hvm.h>
>   #include <asm/hvm/support.h>
> +#include <asm/hvm/nestedhvm.h>
>   #include <asm/debugreg.h>
>   #include <asm/msr.h>
>   #include <asm/traps.h>
> @@ -704,9 +705,13 @@ int arch_set_info_guest(
>           /* PVH 32bitfixme */
>           ASSERT(!compat);
>
> -        if ( c(ctrlreg[1]) || c(ldt_base) || c(ldt_ents) ||
> +        if ( (c(ctrlreg[0]) & HVM_CR0_GUEST_RESERVED_BITS) ||
> +             (c(ctrlreg[4]) & HVM_CR4_GUEST_RESERVED_BITS(v)) ||

Good idea. :-)

> +             c(ctrlreg[1]) || c(ctrlreg[2]) || c(ctrlreg[5]) ||
> +             c(ctrlreg[6]) || c(ctrlreg[7]) || c(ldt_base) || c(ldt_ents) ||
>                c(user_regs.cs) || c(user_regs.ss) || c(user_regs.es) ||
>                c(user_regs.ds) || c(user_regs.fs) || c(user_regs.gs) ||
> +             c(kernel_ss) || c(kernel_sp) || c.nat->gs_base_kernel ||
>                c.nat->gdt_ents || c.nat->fs_base || c.nat->gs_base_user )
>               return -EINVAL;
>       }
> @@ -745,17 +750,20 @@ int arch_set_info_guest(
>
>       if ( has_hvm_container_vcpu(v) )
>       {
> -        /*
> -         * NB: TF_kernel_mode is set unconditionally for HVM guests,
> -         * so we always use the gs_base_kernel here. If we change this
> -         * function to imitate the PV functionality, we'll need to
> -         * make it pay attention to the kernel bit.
> -         */
> -        hvm_set_info_guest(v, compat ? 0 : c.nat->gs_base_kernel);

I think we still need to call hvm_set_info_guest() here -- there is 
other stuff being set up, and it was called (without the extra argument 
for gs_base_kernel) before the PVH patch series went in.

(See c/s 35b1e07.)

>
>           if ( is_hvm_vcpu(v) || v->is_initialised )
>               goto out;
>
> +        if ( c.nat->ctrlreg[0] ) {
> +            v->arch.hvm_vcpu.guest_cr[0] |= c.nat->ctrlreg[0];
> +            hvm_update_guest_cr(v, 0);
> +        }
> +
> +        if ( c.nat->ctrlreg[4] ) {
> +            v->arch.hvm_vcpu.guest_cr[4] |= c.nat->ctrlreg[4];
> +            hvm_update_guest_cr(v, 4);
> +        }

I thought the idea was that he would set cr0, cr3, and cr4 for all HVM 
guests, rather than special-casing PVH guests?

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2013-11-19 10:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 18:18 [PATCH RFC v2] pvh: clearly specify used parameters in vcpu_guest_context Roger Pau Monne
2013-11-18 22:30 ` Mukesh Rathor
2013-11-19 11:11   ` George Dunlap
2013-11-19 10:34 ` George Dunlap [this message]
2013-11-19 10:42   ` Roger Pau Monné
2013-11-19 11:10     ` George Dunlap
2013-11-19 10:44   ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528B3EA3.9090008@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).