On 23.11.2012, at 23:07, Paul Mackerras wrote: > On Fri, Nov 23, 2012 at 04:43:03PM +0100, Alexander Graf wrote: >> >> On 22.11.2012, at 10:28, Paul Mackerras wrote: >> >>> - With the possibility of the host paging out guest pages, the use of >>> H_LOCAL by an SMP guest is dangerous since the guest could possibly >>> retain and use a stale TLB entry pointing to a page that had been >>> removed from the guest. >> >> I don't understand this part. Don't we flush the TLB when the page gets >> evicted from the shadow HTAB? > > The H_LOCAL flag is something that we invented to allow the guest to > tell the host "I only ever used this translation (HPTE) on the current > vcpu" when it's removing or modifying an HPTE. The idea is that that > would then let the host use the tlbiel instruction (local TLB > invalidate) rather than the usual global tlbie instruction. Tlbiel is > faster because it doesn't need to go out on the fabric and get > processed by all cpus. In fact our guests don't use it at present, > but we put it in because we thought we should be able to get a > performance improvement, particularly on large machines. > > However, the catch is that the guest's setting of H_LOCAL might be > incorrect, in which case we could have a stale TLB entry on another > physical cpu. While the physical page that it refers to is still > owned by the guest, that stale entry doesn't matter from the host's > point of view. But if the host wants to take that page away from the > guest, the stale entry becomes a problem.
That's exactly where my question lies. Does that mean we don't flush the TLB entry regardless when we take the page away from the guest? Alex > > The solution I implement here is just not to use tlbiel in SMP guests. > UP guests are not so much of a problem because the potential attack > from the guest relies on having one cpu remove the HPTE and do tlbiel > while another cpu uses the stale TLB entry, which you can't do if you > only have one cpu. > > Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
