> > > > The previous patch regards PCID and INVPCID as a whole because qemu > doesn't support cpuid leaf 7 configuration at present. This is not the case in this > version. > > > The problem with cpu_has_hypervisor check is that its Linux specific. > > > Any solution should also take into account other OSes running as L1 > > > guest and virtualizing L2 guest. > > > > Is there any other way, which applies to all host hypervisors, to know if kvm is > running as a guest hypervisor? > > The point is that other hypervisor might be running as L1 guest. > > The problem with enabling PCID for the L2 guest is that it can share same PCID > values with the L1 hypervisor. > > However, if the L1 hypervisor enables and configures VPID (given that > the L0 hypervisor emulates and exposes it), there is no problem in enabling > PCID for both L1 and L2 guests because TLB entries will be differentiated by > their VPID values, even if their PCID values are the same. > This may not be a problem because: 1. If both L1 and L2 use VPID, there's no problem as you have mentioned. 2. If neither L1 and L2 use VPID, the TLB entries are all tagged with VPID 0 and any VM entries or exits will invalidate them. 3. If one of L1 and L2 uses VPID but the other don't, the TLB entries still have different VPID and won't affect each other. I haven't thought over exposing PCID to L2 guests before but it seems that no problem exists in exposing PCID to L2 guests. Is it looks ok to you if PCID is always exposed, no matter for L1 or L2 guests? > So i think that checking whether EPT _and_ VPID are supported should be a > precondition to enable PCID support for guests. > Should this check be carried out on L0 too? If so, this will add one more dependency of PCID on VPID, which doesn't exist in the manual. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
