Re: [Xen-devel] [PATCH v4 11/26] xen/x86: Improvements to in-hypervisor cpuid sanity checks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.03.16 at 17:36, <andrew.cooper3@xxxxxxxxxx> wrote:
> +        if ( !is_pvh_domain(currd) )
>          {
> -            __clear_bit(X86_FEATURE_XSAVE % 32, &c);
> -            __clear_bit(X86_FEATURE_AVX % 32, &c);
> +            /*
> +             * Delete the PVH condition when HVMLite formally replaces PVH,
> +             * and HVM guests no longer enter a PV codepath.
> +             */
> +
> +            /* OSXSAVE cleared by pv_featureset.  Fast-forward CR4 back in. 
> */
> +            if ( (is_pv_domain(currd) && guest_kernel_mode(curr, regs) &&
> +                  (read_cr4() & X86_CR4_OSXSAVE)) ||
> +                 (curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_OSXSAVE) )
> +                c |= cpufeat_mask(X86_FEATURE_OSXSAVE);
>          }

The is_pv_domain() is now redundant with the is_pvh_domain()
earlier on, and it would likely end up confusing the reader if on
the right side of the || then ->arch.pv_vcpu is being referenced.

With that addressed, the commit message updated as already
indicated and ...

> +        /*
> +         * PV guests cannot use any MTRR infrastructure, so shouldn't see the
> +         * feature bit.  It used to leak in to PV guests.
> +         *
> +         * PVOPS Linux self-clobbers the MTRR feature, to avoid trying to use

... this starting "Modern PVOPS Linux self-clobbers ...":
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


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