On 01/20/2010 11:57 AM, Sheng Yang wrote:
No protection for ring->first and ring->last? Seems it can writing the
same element pointed by ring->first twice, then skip one element at
(ring->first + 1)...
ring->first is owned by userspace, while ring->last is owned by the
kernel, so no protection is necessary except for the memory barrier.
Can you elaborate on how it would fail?
This piece of code can only be executed on one thread/vcpu at same time? I
think different vcpus accessing/modifying ring->first at the same time would
cause problem.
Yes, it's protected by qemu_lock.
But for a separate iothread which handle all userspace accessing, it should be
fine.
coalesced mmio processing can happen as part of vcpu processing (due to
an mmio exit) or by the iothread (forced by the display refresh timer
for example), but still serialized by qemu_lock.
--
error compiling committee.c: too many arguments to function
--
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
