From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48109) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URv3O-0007bI-K5 for qemu-devel@nongnu.org; Mon, 15 Apr 2013 21:51:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URv3M-0001Bn-3q for qemu-devel@nongnu.org; Mon, 15 Apr 2013 21:51:26 -0400 Received: from mail-da0-x232.google.com ([2607:f8b0:400e:c00::232]:60806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URv3L-0001Bg-NN for qemu-devel@nongnu.org; Mon, 15 Apr 2013 21:51:24 -0400 Received: by mail-da0-f50.google.com with SMTP id t1so2336915dae.37 for ; Mon, 15 Apr 2013 18:51:21 -0700 (PDT) Message-ID: <516CAE8F.3030905@gmail.com> Date: Tue, 16 Apr 2013 09:51:11 +0800 From: puckbee MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080801020401010200080305" Subject: [Qemu-devel] The details of round robin of multi-vcpu in TCG mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------080801020401010200080305 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Hi there: Sorry to post this problem a second time, for I thought maybe the question is not descripted clearly. I'm studying the execution details of multi-vcpu in TCG mode. The vcpus in TCG mode are executed one by one in a sequencial way, according to some articles about Qemu. I read the function [tcg_exec_all] in Qemu 1.3.0 as bellow, but the implementation is not as expected. [tcg_exec_all] will finally call [cpu_exec] to excute a loop to excute the TBs in code cache So,how does these functions control the running time of each VCPU? That is,when will the execution of one VCPU return, in order to execute the next_cpu in the loop of [tcg_exec_all]. Using alarm timer or other methonds? staticvoidtcg_exec_all(void) { intr; /* Account partial waits to the vm_clock. */ qemu_clock_warp(vm_clock); if(next_cpu==NULL){ next_cpu=first_cpu; } *for(;next_cpu!=NULL&&!exit_request;next_cpu=next_cpu->next_cpu){* CPUArchState*env=next_cpu; CPUState*cpu=ENV_GET_CPU(env); qemu_clock_enable(vm_clock, (env->singlestep_enabled&SSTEP_NOTIMER)==0); if(cpu_can_run(cpu)){ ***r****=****tcg_cpu_exec**(**env**);* if(r==EXCP_DEBUG){ cpu_handle_guest_debug(env); break; } }elseif(cpu->stop||cpu->stopped){ break; } } exit_request=0; } Yours Puck --------------080801020401010200080305 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 7bit Hi there:

    Sorry to post this problem a second time, for I thought maybe the question is not descripted clearly.

    I'm studying the execution details of multi-vcpu in TCG mode.

    The vcpus in TCG mode are executed one by one in a sequencial way, according to some articles about Qemu.

    I read the function [tcg_exec_all] in Qemu 1.3.0 as bellow, but the implementation is not as expected.

    [tcg_exec_all] will finally call [cpu_exec] to excute a loop to excute the TBs in code cache

    So,how does these functions control the running time of each VCPU?
    
    That is,when will the execution of one VCPU return, in order to execute the next_cpu in the loop of [tcg_exec_all].

    Using alarm timer or other methonds?

static void tcg_exec_all(void)
{
    
int r;

    
/* Account partial waits to the vm_clock.  */
    
qemu_clock_warp(vm_clock);

    
if (next_cpu == NULL) {
        
next_cpu = first_cpu;
    
}
    
for (; next_cpu != NULL && !exit_request; next_cpu = next_cpu->next_cpu) {
        
CPUArchState *env = next_cpu;
        
CPUState *cpu = ENV_GET_CPU(env);

        
qemu_clock_enable(vm_clock,
                          
(env->singlestep_enabled & SSTEP_NOTIMER) == 0);

        
if (cpu_can_run(cpu)) {
            
r = tcg_cpu_exec(env);
            
if (r == EXCP_DEBUG) {
                
cpu_handle_guest_debug(env);
                
break;
            
}
        
} else if (cpu->stop || cpu->stopped) {
            
break;
        
}
    
}
    
exit_request = 0;
}

Yours
Puck --------------080801020401010200080305-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URw3a-0003je-BJ for qemu-devel@nongnu.org; Mon, 15 Apr 2013 22:55:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URw3Y-0004fF-45 for qemu-devel@nongnu.org; Mon, 15 Apr 2013 22:55:42 -0400 Received: from [222.73.24.84] (port=51211 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URw3X-0004dx-PR for qemu-devel@nongnu.org; Mon, 15 Apr 2013 22:55:40 -0400 From: li guang In-Reply-To: <516CAE8F.3030905@gmail.com> References: <516CAE8F.3030905@gmail.com> Date: Tue, 16 Apr 2013 10:53:58 +0800 Message-ID: <1366080838.20662.12.camel@liguang.fnst.cn.fujitsu.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] The details of round robin of multi-vcpu in TCG mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: puckbee Cc: qemu-devel@nongnu.org You can find the chance of exit main loop by every calling of cpu_loop_exit() in cpu_exec(). =E5=9C=A8 2013-04-16=E4=BA=8C=E7=9A=84 09:51 +0800=EF=BC=8Cpuckbee=E5=86=99= =E9=81=93=EF=BC=9A > Hi there: >=20 > Sorry to post this problem a second time, for I thought maybe the > question is not descripted clearly. >=20 > I'm studying the execution details of multi-vcpu in TCG mode. >=20 > The vcpus in TCG mode are executed one by one in a sequencial way, > according to some articles about Qemu. >=20 > I read the function [tcg_exec_all] in Qemu 1.3.0 as bellow, but > the implementation is not as expected. >=20 > [tcg_exec_all] will finally call [cpu_exec] to excute a loop to > excute the TBs in code cache >=20 > So,how does these functions control the running time of each VCPU? > =20 > That is,when will the execution of one VCPU return, in order to > execute the next_cpu in the loop of [tcg_exec_all]. >=20 > Using alarm timer or other methonds? >=20 > static void tcg_exec_all(void) > { > int r; > =20 > /* Account partial waits to the vm_clock. */ > qemu_clock_warp(vm_clock); > =20 > if (next_cpu =3D=3D NULL) { > next_cpu =3D first_cpu; > } > for (; next_cpu !=3D NULL && ! > exit_request; next_cpu =3D next_cpu->next_cpu) { > CPUArchState *env =3D next_cpu; > CPUState *cpu =3D ENV_GET_CPU(env); > =20 > qemu_clock_enable(vm_clock, > (env->singlestep_enabled & SSTE= P_NOTIMER) =3D=3D 0); > =20 > if (cpu_can_run(cpu)) { > r =3D tcg_cpu_exec(env); > if (r =3D=3D EXCP_DEBUG) { > cpu_handle_guest_debug(env); > break; > } > } else if (cpu->stop || cpu->stopped) { > break; > } > } > exit_request =3D 0; > } > =20 > Yours > Puck=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USncM-0002iU-8B for qemu-devel@nongnu.org; Thu, 18 Apr 2013 08:07:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USncJ-0004Qc-HL for qemu-devel@nongnu.org; Thu, 18 Apr 2013 08:07:10 -0400 Received: from mail-da0-x235.google.com ([2607:f8b0:400e:c00::235]:33027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USnPr-00006V-E4 for qemu-devel@nongnu.org; Thu, 18 Apr 2013 07:54:15 -0400 Received: by mail-da0-f53.google.com with SMTP id n34so1329790dal.12 for ; Thu, 18 Apr 2013 04:54:14 -0700 (PDT) Message-ID: <516FDEDA.70701@gmail.com> Date: Thu, 18 Apr 2013 19:54:02 +0800 From: puckbee MIME-Version: 1.0 References: <516CAE8F.3030905@gmail.com> <1366080838.20662.12.camel@liguang.fnst.cn.fujitsu.com> In-Reply-To: <1366080838.20662.12.camel@liguang.fnst.cn.fujitsu.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Is Qemu now support x2apic in TCG mode? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi there: Is there somebody can tell me that if qemu can support x2apic now? I've seen the x2apic in the definition of cpu flags, but can not find any implementation about x2apic. Thanks a lot if somebody can give me some hints~ puck 2013.4.18