On 14/05/2018 21:59, Liran Alon wrote: >> I agree that your approach should result in less code. I am not sure >> where you stored the PCID bits, but if it's the hash key, then we >> might >> as well store fewer and force a TLB flush when there is a conflict. >> This should limit the amount of memory used by SPTEs. > To which PCID bits are you referring? > > For every SPT I have added a 12-bit field for storing active PCID when SPT was created. My idea here is to only store say the least significant 4 bits, and for each 4 bits you store the full 12-bit field in a side array, and you also keep separate generation counts. If you get a conflict, you flush the SPTs for those four bits. But that would be just a refinement of your idea. > Unrelated, to support INVPCID, I added a per-vCPU bitmap of 0x1000 bits (512 bytes) that signals > to which PCIDs on next switch to them, we should force a SPT sync & TLB flush even if new CR3 bit 63 is set. > Because the bitmap is per-vCPU, it doesn't take memory from SPTs. > > The reason I said my approach consumes more SPT pages is because SPTs mirroring the same GPT in same > paging-mode and same paging-level are duplicated between different PCIDs. > > Also, I didn't quite got your opinion regarding the trade-off between the different approaches. I prefer yours, as it's simpler code. Paolo
