Re: [Xen-devel] [PATCH 4/6] libxc: expose xsaves/xgetbv1/xsavec to hvm guest

["Jan Beulich" <JBeulich@xxxxxxxx>]

Please don't top post.

>>> On 21.07.15 at 11:33, <shuai.ruan@xxxxxxxxx> wrote:
> Thanks for your reviews Jan.
> Can you give me some suggestion on this?  In PATCH03, I change hvm_cpuid 
> function to make sure the CPUID data can be exposed to guest when xsaves 
> supported.  

Not sure what recommendations you're after - just follow the current
model of white listing what we know we can/do support. Don't pass to
the guest any bits you don't know whether other code changes are
going to be needed in order for a guest to safely make use of the
respective feature.

Jan

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] 
> Sent: Friday, July 17, 2015 6:47 PM
> To: Ruan, Shuai
> Cc: andrew.cooper3@xxxxxxxxxx; Ian.Campbell@xxxxxxxxxx; wei.liu2@xxxxxxxxxx; 
> ian.jackson@xxxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx; Dong, Eddie; 
> Nakajima, Jun; Tian, Kevin; xen-devel@xxxxxxxxxxxxx; keir@xxxxxxx 
> Subject: RE: [PATCH 4/6] libxc: expose xsaves/xgetbv1/xsavec to hvm guest
> 
>>>> On 17.07.15 at 10:10, <shuai.ruan@xxxxxxxxx> wrote:
>> Ok, Thanks Jan.
>> I will add the descriptions in next version.
>> 
>> Below is the short descriptions.
>> For CPUID with eax=0xd and ecx=0x1, ebx\ecx\edx may not be zero when 
>> xsaves supported. Also with ecx>2, ecx\edx may not be zero. If we want 
>> expose xsaves to HVM guest , we should not set them to zero.
>> 
>> So in your opinions ,is it proper to add these code here?
> 
> Sure, provided you don't leak any bits that may become defined in the 
> future, and the non-zero setting of which might be inconsistent with other 
> CPUID data. I.e. without looking at the manual, I'd guess the above is still 
> a little too vague.
> 
> Jan




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