From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rwr63-00072B-AZ for qemu-devel@nongnu.org; Mon, 13 Feb 2012 03:17:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rwr5y-00030y-ST for qemu-devel@nongnu.org; Mon, 13 Feb 2012 03:17:15 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:45400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rwr5y-00030f-LQ for qemu-devel@nongnu.org; Mon, 13 Feb 2012 03:17:10 -0500 Received: by pbbro12 with SMTP id ro12so5051674pbb.4 for ; Mon, 13 Feb 2012 00:17:09 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F38C6FC.5040908@redhat.com> Date: Mon, 13 Feb 2012 09:17:00 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <4F363DB2.3080908@web.de> <4F3655E7.3090905@suse.de> <4F36626D.7020109@web.de> <4F3667BC.9060306@suse.de> <4F36680B.7090400@web.de> <4F366B74.1000501@suse.de> <4F366E9C.8080808@web.de> <4F36742F.2050600@suse.de> <4F36750A.5060304@web.de> <4F36774D.4040405@suse.de> In-Reply-To: <4F36774D.4040405@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 1/8] kvm: Set cpu_single_env only once List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Anthony Liguori , kvm@vger.kernel.org, Gleb Natapov , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Avi Kivity On 02/11/2012 03:12 PM, Andreas Färber wrote: > Yes and no. They can have any target-specific pointer they want, just > as before. But no global first_cpu / cpu_single_env pointer - that's > replaced by CPU pointers, through which members of derived classes can > be accessed (which did not work for CPUState due to CPU_COMMON members > being at target-specific offset in the middle). Hmm, now I'm not even sure what I want that Andreas referred to. :) I definitely would like CPUState pointers to be changed into link properties, but that's not related to what Jan is doing here with cpu_single_env. Each LAPIC refers to a CPU, and that would become a link property indeed. But here we're using cpu_single_env to find out which LAPIC is being read. It's the other direction. Relying on thread-local cpu_single_env means that you restrict LAPIC memory reads to run in VCPU thread context, and this makes sense anyway. The only case of MMIO running in iothread context is Xen, but Xen always keeps the LAPIC in the hypervisor. Also, I think that having a view of CPUs in QOM is laudable, but I don't understand why that means you need to remove first_cpu / cpu_single_env. Finally, CPU_COMMON members may be referenced from TCG-generated code, how do you plan to move them and still keep the TLBs at small offsets within CPUState? Perhaps we need a drawing of the situation before and after the QOMization of CPUs. Paolo