On Tue, Dec 13, 2011 at 12:10 PM, Antonios Motakis
<[email protected]> 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<[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
