Re: [Xen-devel] [PATCH v2 12/30] xen/x86: Generate deep dependencies of features

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.02.16 at 11:25, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/02/16 09:54, Jan Beulich wrote:
>>>>> On 15.02.16 at 20:07, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 15/02/16 16:27, Jan Beulich wrote:
>>>>>>> On 15.02.16 at 17:09, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> The key point is this.  If I choose to enable XSAVE and disable AVX for
>>>>> a domain, that domain is unable to FMA/FMA4/F16C instructions.  It
>>>>> therefore shouldn't see the features.
>>>> Are you sure? Did you try?
>>> Yes
>>>
>>> void test_main(void)
>>> {
>>>     printk("AVX Testing\n");
>>>
>>>     write_cr4(read_cr4() | X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT | 
>>> X86_CR4_OSXSAVE);
>>>
>>>     asm volatile ("xsetbv" :: "a" (0x7), "d" (0), "c" (0));
>>>     asm volatile ("vfmadd132pd %xmm0, %xmm1, %xmm2");
>>>
>>>     asm volatile ("xsetbv" :: "a" (0x3), "d" (0), "c" (0));
>>>     asm volatile ("vfmadd132pd %xmm0, %xmm1, %xmm2");
>> Here you clear the bit in XCR0, which wasn't the question. The
>> question was whether VFMADD... would fault when the CPUID
>> AVX bit is clear.
> 
> How will the pipeline know whether the guest was offered the AVX flag in
> cpuid?
> 
> Hiding feature bits does not prevent the functionality from working. 
> i.e. 1GB superpages don't stop working if you hide the feature bit.  No
> amount of levelling can stop a guest from manually probing for
> features/instruction sets.

That wasn't my point. I was intentionally referring to the CPUID
bits, knowing that us masking them in software doesn't affect
hardware in any way. Hence the "Are you sure? Did you try?"
which were really meant in a rhetorical way, as the answer can
only possible be "no" here (unless you had control over the
hardware).

Jan


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