On Tue, Dec 13, 2011 at 12:10 PM, Antonios Motakis <a.motakis@xxxxxxxxxxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxx> 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. > yes, this is going to be a simple per-vm implementation that flushes TLBs on roll-over for the next patch series, let's leave it at that for now! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
