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

Re: [Xen-devel] [V0 PATCH 1/6] AMD-PVH: construct vmcb changes

On 08/18/2014 07:46 PM, Mukesh Rathor wrote:
On Mon, 18 Aug 2014 11:10:54 +0200
Roger Pau Monnà <roger.pau@xxxxxxxxxx> wrote:

On 16/08/14 03:53, Mukesh Rathor wrote:
PVH guest starts in Long 64bit paging mode. This patch modifies
construct_vmcb for that.

Signed-off-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
  xen/arch/x86/hvm/svm/vmcb.c | 18 +++++++++++++++---
  1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vmcb.c
b/xen/arch/x86/hvm/svm/vmcb.c index 21292bb..5df5f36 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -138,6 +138,8 @@ static int construct_vmcb(struct vcpu *v)
/* Guest EFER. */
      v->arch.hvm_vcpu.guest_efer = 0;
+    if ( is_pvh_vcpu(v) )
+        v->arch.hvm_vcpu.guest_efer |= EFER_LMA;   /* PVH
32bitfixme */ hvm_update_guest_efer(v);

I know this is already done on Intel in order to boot PVH guests, but
now that we know what we need to modify in both Intel and AMD HVM
code, do you think it would we suitable to add another parameter to
vcpu_initialise in order to tell it to setup the vcpu to boot into
long (or protected if we support 32bit PVH guests) mode (and prevent
adding more is_pvh_vcpu)?
Well, we can defer adding parameter to vcpu_initialise to when 32bit
work gets done. For now, we could move common hvm fields initialization
to hvm_vcpu_initialise.. that way, we'd have fewer is_pvh. I can
submit a patch if Jan is ok with that.

Setting LMA bit for PVH guest is in fact already done by hvm_vcpu_initialise() so the change above is unnecessary.


Xen-devel mailing list



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