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<a...@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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
