[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.