Re: [Qemu-devel] Re: Release of COREMU, a scalable and portable full-system emulator

[Stefan Hajnoczi]

2010/7/23 wang Tiger <address@hidden>:
> 在 2010年7月23日 下午5:13，Stefan Hajnoczi <address@hidden> 写道：
>> 2010/7/23 Alexander Graf <address@hidden>:
>>>
>>> On 23.07.2010, at 09:53, Jan Kiszka wrote:
>>>
>>>> wang Tiger wrote:
>>>>> 在 2010年7月22日 下午11:47，Stefan Hajnoczi <address@hidden> 写道：
>>>>>> 2010/7/22 wang Tiger <address@hidden>:
>>>>>>> In our implementation for x86_64 target, all devices except LAPIC are
>>>>>>> emulated in a seperate thread. VCPUs are emulated  in other threads
>>>>>>> (one thread per VCPU).
>>>>>>> By observing some device drivers in linux, we have a hypothethis that
>>>>>>> drivers in OS have already ensured correct synchronization on
>>>>>>> concurrent hardware accesses.
>>>>>> This hypothesis is too optimistic.  If hardware emulation code assumes
>>>>>> it is only executed in a single-threaded fashion, but guests can
>>>>>> execute it in parallel, then this opens up the possibility of race
>>>>>> conditions that malicious guests can exploit.  There needs to be
>>>>>> isolation: a guest should not be able to cause QEMU to crash.
>>>>>
>>>>> In our prototype, we assume the guest behaves correctly. If hardware
>>>>> emulation code can ensure atomic access(behave like real hardware),
>>>>> VCPUS can access device freely.  We actually refine some hardward
>>>>> emulation code (eg. BMDMA, IOAPIC ) to ensure the atomicity of
>>>>> hardware access.
>>>>
>>>> This approach is surely helpful for a prototype to explore the limits.
>>>> But it's not applicable to production systems. It would create a huge
>>>> source of potential subtle regressions for other guest OSes,
>>>> specifically those that you cannot analyze regarding synchronized
>>>> hardware access. We must play safe.
>>>>
>>>> That's why we currently have the global mutex. Its conversion can only
>>>> happen step-wise, e.g. by establishing an infrastructure to declare the
>>>> need of device models for that Big Lock. Then you can start converting
>>>> individual models to private locks or even smart lock-less patterns.
>>>
>>> But isn't that independent from making TCG atomic capable and parallel? At 
>>> that point a TCG vCPU would have the exact same issues and interfaces as a 
>>> KVM vCPU, right? And then we can tackle the concurrent device access issues 
>>> together.
>>
>> An issue that might affect COREMU today is core QEMU subsystems that
>> are not thread-safe and used from hardware emulation, for example:
>>
>> cpu_physical_memory_read/write() to RAM will use qemu_get_ram_ptr().
>> This function moves the found RAMBlock to the head of the global RAM
>> blocks list in a non-atomic way.  Therefore, two unrelated hardware
>> devices executing cpu_physical_memory_*() simultaneously face a race
>> condition.  I have seen this happen when playing with parallel
>> hardware emulation.
>>
>> Tiger: If you are only locking the hardware thread for ARM target,
>> your hardware emulation is not safe for other targets.  Have I missed
>> something in the COREMU patch that defends against this problem?
>>
>> Stefan
>>
> In fact, we solve this problem through a really simple method.
> In our prototype, we removed this piece of code like this:
> void *qemu_get_ram_ptr(ram_addr_t addr)
> {
>    ......
>
>    /* Move this entry to to start of the list.  */
> #ifndef CONFIG_COREMU
>    /* Different core can access this function at the same time.
>     * For coremu, disable this optimization to avoid data race.
>     * XXX or use spin lock here if performance impact is big. */
>    if (prev) {
>        prev->next = block->next;
>        block->next = *prevp;
>        *prevp = block;
>    }
> #endif
>    return block->host + (addr - block->offset);
> }
>
> CONFIG_COREMU is defined when TCG parallel mode is configured.
> And the list is more likely to be read only without hotplug device, so
> we don't use a lock to protect it.
> Reimplement this list with a lock free list is also reasonable, but
> seems unnecessary. :-)

Ah, good :).

Stefan

> --
> Zhaoguo Wang, Parallel Processing Institute, Fudan University
>
> Address: Room 320, Software Building, 825 Zhangheng Road, Shanghai, China
>
> address@hidden
> http://ppi.fudan.edu.cn/zhaoguo_wang
>