Please don't top post. >>> On 21.07.15 at 11:33, <[email protected]> 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:[email protected]] > Sent: Friday, July 17, 2015 6:47 PM > To: Ruan, Shuai > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; Dong, Eddie; > Nakajima, Jun; Tian, Kevin; [email protected]; [email protected] > Subject: RE: [PATCH 4/6] libxc: expose xsaves/xgetbv1/xsavec to hvm guest > >>>> On 17.07.15 at 10:10, <[email protected]> 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 [email protected] http://lists.xen.org/xen-devel
