Re: [PATCH v1 4/6] vvmx: add hvm_max_vmx_msr_policy

[Sergey Dyasli <sergey.dyasli@citrix.com>]

On Thu, 2017-07-06 at 06:28 -0600, Jan Beulich wrote:
> > > > On 06.07.17 at 12:23, <sergey.dyasli@citrix.com> wrote:
> > 
> > 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.
> 
> Are there any other (reasonable) ones, besides forbidding
> migration (live or not). Otoh, if migration between hosts with
> different IDs is allowed, won't we risk the page layout (which
> is intentionally unknown to us) changing as well? Or in order
> to be migrateable, such guests would have to be forced to
> not use shadow VMCS, and we'd have to pin down (as part of
> the guest ABI) the software layout we use.

During a discussion with Andrew, we identified difficulties in migration
of an L1 hypervisor to a H/W with the different vmcs revision id when
VMCS shadowing is used.

It seems to be a reasonable requirement for migration to have H/W with
the same vmcs revision id. Therefore it is fine to provide L1 with
the real H/W id and I will remove that comment in v2.

-- 
Thanks,
Sergey
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel