From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [Qemu-devel] [PATCH v2 1/8] kvm: Set cpu_single_env only once Date: Mon, 13 Feb 2012 09:17:00 +0100 Message-ID: <4F38C6FC.5040908@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jan Kiszka , Blue Swirl , Anthony Liguori , kvm@vger.kernel.org, Gleb Natapov , Marcelo Tosatti , qemu-devel , Avi Kivity To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Return-path: Received: from mail-pz0-f46.google.com ([209.85.210.46]:48805 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978Ab2BMIRJ (ORCPT ); Mon, 13 Feb 2012 03:17:09 -0500 Received: by daed14 with SMTP id d14so4258907dae.19 for ; Mon, 13 Feb 2012 00:17:09 -0800 (PST) In-Reply-To: <4F36774D.4040405@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 02/11/2012 03:12 PM, Andreas F=C3=A4rber 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 ca= n > be accessed (which did not work for CPUState due to CPU_COMMON member= s > 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=20 properties, but that's not related to what Jan is doing here with=20 cpu_single_env. Each LAPIC refers to a CPU, and that would become a=20 link property indeed. But here we're using cpu_single_env to find out=20 which LAPIC is being read. It's the other direction. Relying on thread-local cpu_single_env means that you restrict LAPIC=20 memory reads to run in VCPU thread context, and this makes sense anyway= =2E=20 The only case of MMIO running in iothread context is Xen, but Xen=20 always keeps the LAPIC in the hypervisor. Also, I think that having a view of CPUs in QOM is laudable, but I don'= t=20 understand why that means you need to remove first_cpu / cpu_single_env= =2E =46inally, CPU_COMMON members may be referenced from TCG-generated code= ,=20 how do you plan to move them and still keep the TLBs at small offsets=20 within CPUState? Perhaps we need a drawing of the situation before and= =20 after the QOMization of CPUs. Paolo