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.
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.
