Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.12.11 at 11:01, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> Liu, Jinsong wrote:
>> Jan Beulich wrote:
>>>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>>>> wrote: 
>>>> Jan Beulich wrote:
>>>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>>>>>> wrote:
>>>>>> This patch disable PCID/INVPCID for dom0.
>>>>> 
>>>>> Do we really need to disable it, rather than making it work?
>>>>> Conceptually the feature seems usable, and the instruction would
>>>>> need replacement by a hypercall anyway (just like invlpg).
>>>> 
>>>> It's a design choice.
>>>> Exposing PCID/INVPCID to pv would involve some additional task, like
>>>> coordinated PCID allocation algorithm, or change vmm vcpu context
>>>> swich, which would make it complex. However, exposing PCID/INVPCID
>>>> to pv has not obvious benefit or even result in performance
>>>> regression.
>>> 
>>> Would you mind elaborating on that statement?
>>> 
>>> Jan
>> 
>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>> conflict, which make processor confused at TLB. 
>> To make PCID work at pv, it need
>> 1, either a coordinated PCID allocation algorithm, so that the local
>> PCID of pv domain can be changed to a global unique PCID; 2, or, a
>> 'clean' vcpu context switch logic to flush all TLB; 
>> method 1 make things complex w/o obvious benefit;
>> method 2 need change current vcpu context switch logic (i.e, mov cr3
>> only flush TLB entries of specific PCID if PCID enabled), and if
>> flush *all* TLB is required at context switch, we lose the change to
>> optimize context switch by partly flush TLB case by case, which may
>> result in performance regression;    
>> 
>> Thanks,
>> Jinsong
> 
> Jan, any comments? Thanks, Jinsong

No, no further comments (just don't have the time right now to think
through the possible alternatives). So for the moment I think things
could go in as posted by you. It's not immediately clear though
whether the series needs to be applied in order (it would seem that's
not a requirement, but I'd like your confirmation), as I could at most
take care of patches 2, 3, and 6.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel