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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/07/17 14:01, Sergey Dyasli wrote:
> On Thu, 2017-07-06 at 06:28 -0600, Jan Beulich wrote:
>>>>> On 06.07.17 at 12:23, <sergey.dyasli@xxxxxxxxxx> wrote:
>>> On Tue, 2017-07-04 at 09:04 -0600, Jan Beulich wrote:
>>>>>>> On 26.06.17 at 12:44, <sergey.dyasli@xxxxxxxxxx> 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.

From the point of view of the L1 guest which is using nested-virt, it
reads VMX_BASIC at the start of day to get the revision id.  This is
just like reading the CPUID information at the start of day, and
expecting it to remain constant until the next reboot.

If Xen is fully shadowing the VMCS, and Xen's advertised revision ID
hasn't changed, then migration between different hardware is possible
(providing that the guest was first booted with all other VMX features
suitably levelled), as Xen has to shadow everything the guest vmwrote
anyway.

If Xen uses VMCS shadowing to speed up the L1 guests vmread/vmwrites,
then migration must be locked to hardware with the same revision id.  If
we don't fulfil this requirement, Xen wouldn't be able to (validly)
object to the L1 guest doing a vmptrld with the old revision ID, and
wouldn't be in a position (at all, let alone validly) to re-serialise
the VMCS in place to be suitable for the current hardware.

~Andrew

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