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

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Jan Beulich wrote:
>>>> 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

Do you mean checkin patches 2/3/6 first?
It's OK to checkin patches 2/3/6 first, they are ./xen code, no 
order-dependence with patches 1/4/5 (which are ./tools code).

Thanks,
Jinsong


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