From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Cc: Sergey Dyasli <sergey.dyasli@citrix.com>,
Kevin Tian <kevin.tian@intel.com>,
Andrew Cooper <Andrew.Cooper3@citrix.com>,
"jun.nakajima@intel.com" <jun.nakajima@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v1 4/6] vvmx: add hvm_max_vmx_msr_policy
Date: Thu, 6 Jul 2017 10:23:47 +0000 [thread overview]
Message-ID: <1499336627.3082.6.camel@citrix.com> (raw)
In-Reply-To: <595BCA8C02000078001686EC@prv-mh.provo.novell.com>
On Tue, 2017-07-04 at 09:04 -0600, Jan Beulich wrote:
> > > > On 26.06.17 at 12:44, <sergey.dyasli@citrix.com> wrote:
> >
> > +{
> > + struct vmx_msr_policy *p = &hvm_max_vmx_msr_policy;
> > + uint64_t data, *msr;
> > + u32 default1_bits;
> > +
> > + *p = raw_vmx_msr_policy;
> > +
> > + /* XXX: vmcs_revision_id for nested virt */
>
> There was no such comment (presumably indicating something that
> yet needs doing) in the old code - what's this about? Can't this be
> implemented instead of such a comment be added?
Currently L1 sees vmcs_revision_id value from the H/W MSR. Which is
fine until live migration is concerned. The question is: what should
happen if L1 is migrated to some other H/W with different vmcs id?
One possible solution is to use "virtual vmcs id" in the policy object.
--
Thanks,
Sergey
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-07-06 10:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-26 10:44 [PATCH v1 0/6] VMX MSRs policy for Nested Virt: part 1 Sergey Dyasli
2017-06-26 10:44 ` [PATCH v1 1/6] vmx: add struct vmx_msr_policy Sergey Dyasli
2017-07-04 13:57 ` Jan Beulich
2017-07-06 9:21 ` Sergey Dyasli
2017-07-06 9:59 ` Jan Beulich
2017-07-05 3:02 ` Tian, Kevin
2017-06-26 10:44 ` [PATCH v1 2/6] vmx: add raw_vmx_msr_policy Sergey Dyasli
2017-07-04 14:15 ` Jan Beulich
2017-07-06 9:29 ` Sergey Dyasli
2017-07-06 9:45 ` Jan Beulich
2017-06-26 10:44 ` [PATCH v1 3/6] vmx: refactor vmx_init_vmcs_config() Sergey Dyasli
2017-07-04 14:26 ` Jan Beulich
2017-07-05 3:21 ` Tian, Kevin
2017-06-26 10:44 ` [PATCH v1 4/6] vvmx: add hvm_max_vmx_msr_policy Sergey Dyasli
2017-07-04 15:04 ` Jan Beulich
2017-07-06 10:23 ` Sergey Dyasli [this message]
2017-07-06 12:28 ` Jan Beulich
2017-07-07 13:01 ` Sergey Dyasli
2017-07-07 14:01 ` Andrew Cooper
2017-06-26 10:44 ` [PATCH v1 5/6] vvmx: add per domain vmx msr policy Sergey Dyasli
2017-07-04 15:09 ` Jan Beulich
2017-06-26 10:44 ` [DEBUG PATCH 6/6] vmx: print H/W VMX MSRs values during startup Sergey Dyasli
2017-07-05 2:52 ` [PATCH v1 0/6] VMX MSRs policy for Nested Virt: part 1 Tian, Kevin
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=1499336627.3082.6.camel@citrix.com \
--to=sergey.dyasli@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.