From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35100 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OcG1H-0000Eq-MO for qemu-devel@nongnu.org; Fri, 23 Jul 2010 07:02:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OcG1G-00076H-60 for qemu-devel@nongnu.org; Fri, 23 Jul 2010 07:02:23 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:59519) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OcG1F-000767-UD for qemu-devel@nongnu.org; Fri, 23 Jul 2010 07:02:22 -0400 Received: by vws19 with SMTP id 19so74230vws.4 for ; Fri, 23 Jul 2010 04:02:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <438ED7C1-AD7C-4946-99D2-B0E9A91B8DF1@gmail.com> <6BBDD0C9-39D5-435C-8CD7-4E3DD8BAF57D@gmail.com> <4C472889.5000407@mail.berlios.de> <2FAAD29F-6C3E-4128-A6E1-46EE15AF80FA@gmail.com> <4C484105.5060607@siemens.com> <4C494A60.2040502@web.de> <1D54BA79-2AE5-40B3-813C-676529F1BA49@suse.de> Date: Fri, 23 Jul 2010 12:02:20 +0100 Message-ID: Subject: Re: [Qemu-devel] Re: Release of COREMU, a scalable and portable full-system emulator From: Stefan Hajnoczi Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: wang Tiger Cc: Chen Yufei , Jan Kiszka , Alexander Graf , qemu-devel@nongnu.org 2010/7/23 wang Tiger : > =D4=DA 2010=C4=EA7=D4=C223=C8=D5 =CF=C2=CE=E75:13=A3=ACStefan Hajnoczi =D0=B4=B5=C0=A3=BA >> 2010/7/23 Alexander Graf : >>> >>> On 23.07.2010, at 09:53, Jan Kiszka wrote: >>> >>>> wang Tiger wrote: >>>>> =D4=DA 2010=C4=EA7=D4=C222=C8=D5 =CF=C2=CE=E711:47=A3=ACStefan Hajnoc= zi =D0=B4=B5=C0=A3=BA >>>>>> 2010/7/22 wang Tiger : >>>>>>> In our implementation for x86_64 target, all devices except LAPIC a= re >>>>>>> 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 th= at >>>>>>> drivers in OS have already ensured correct synchronization on >>>>>>> concurrent hardware accesses. >>>>>> This hypothesis is too optimistic. If hardware emulation code assum= es >>>>>> 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 th= e >>>> 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 a= s a KVM vCPU, right? And then we can tackle the concurrent device access is= sues 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 =3D block->next; > block->next =3D *prevp; > *prevp =3D 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 > > tigerwang1986@gmail.com > http://ppi.fudan.edu.cn/zhaoguo_wang >