On 12/12/2011 04:49 PM, Avi Kivity wrote: > On 12/12/2011 05:25 PM, Peter Maydell wrote: >> On 12 December 2011 15:15, Avi Kivity<avi at redhat.com> wrote: >>> We need to differentiate in how Linux-as-a-guest acts and how the cpu is >>> supposed to work. A guest operating system can theoretically assign the >>> ASID x to process A running on vcpu 0, and the same ASID x to process B >>> running on vcpu 1 >> That would be a guest bug. From the ARM ARM: >> "For a symmetric multiprocessor cluster where a single operating system >> is running on the set of processing elements, ARMv7 requires all ASID >> values to be assigned uniquely within any single Inner Shareable domain. >> In other words, each ASID value must have the same meaning to all >> processing elements in the system." > Thanks. So per-vm vmids should work. > We where playing with a VMID recycling patch based on the assumption of per-cpu VMIDs being possible, which would have the advantage of recycling VMIDs without much complicated locking (inspired by the KVM SVM implementation). However we killed it with fire and hot plasma when it became clear it violated the ARM spec... On the other hand, maybe we could do something with per vcpu VMIDs, but with proper synchronization accross physical CPUs in order to be compatible with the spec, but at the same time potentially allow a buggy guest to run? Since in practice a lot of CPUs will not share TLB (and instruction cache) structures, maybe it's possible that there is software out there that violates the spec, without having problems on the real hw. Anyway VMID reuse will be available soon, and the difference between a per vm and per vcpu implementation is a couple of trivial lines of code.
