On 11.06.21 14:03, Paolo Bonzini wrote:
On 11/06/21 14:00, Christian Borntraeger wrote:
What is the semantics of remote_tlb_flush?
I always interpreted it as "number of times the KVM page table management code
needed other CPUs to learn about new page tables". Whether the broadcast is done in
software or hardware shouldn't matter; either way I suppose there is still some traffic
on the bus involved.
My point is that KVM page table management on s390x completely piggy-backs on
the qemu address space page table management from common code for the last
level.
And due to the way we handle page tables we also do not teach "other CPUs". We
always teach the whole system with things like IPTE.
ARM is also not updating the stat, I'll send a patch for that.
Paolo
For the host:
We usually do not do remote TLB flushes in the "IPI with a flush executed on the
remote CPU" sense.
We do have instructions that invalidates table entries and it will take care of
remote TLBs as well (IPTE and IDTE and CRDTE).
This is nice, but on the other side an operating system MUST use these
instruction if the page table might be in use by any CPU. If not, you can get a
delayed access exception machine check if the hardware detect a TLB/page table
incosistency.
Only if you can guarantee that nobody has this page table attached you can also
use a normal store + tlb flush instruction.
For the guest (and I guess thats what we care about here?) TLB flushes are
almost completely handled by hardware. There is only the set prefix instruction
that is handled by KVM and this flushes the cpu local cache.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
