Re: [PATCH v7 1/4] KVM: stats: Separate generic stats from architecture specific ones

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.


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.

[Index of Archives]     [KVM Development]     [KVM ARM]     [KVM ia64]     [Linux Virtualization]     [Linux USB Devel]     [Linux Video]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux