From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HdSSs-0000K2-8z for qemu-devel@nongnu.org; Mon, 16 Apr 2007 10:45:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HdSSq-0000JI-BB for qemu-devel@nongnu.org; Mon, 16 Apr 2007 10:45:57 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HdSSq-0000JA-4K for qemu-devel@nongnu.org; Mon, 16 Apr 2007 10:45:56 -0400 Received: from damascus.uab.es ([158.109.168.135]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HdSOC-0002Ye-Lz for qemu-devel@nongnu.org; Mon, 16 Apr 2007 10:41:09 -0400 Received: from damascus.uab.es ([127.0.0.1]) by damascus.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (built Jan 6 2005)) with ESMTP id <0JGL0066RI4DLG20@damascus.uab.es> for qemu-devel@nongnu.org; Mon, 16 Apr 2007 16:41:01 +0200 (CEST) Received: from [158.109.70.47] by damascus.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (built Jan 6 2005)) with ESMTP id <0JGL006VMI4CM810@damascus.uab.es> for qemu-devel@nongnu.org; Mon, 16 Apr 2007 16:41:01 +0200 (CEST) Date: Mon, 16 Apr 2007 16:41:28 +0200 From: Marius Monton Subject: Re: [Qemu-devel] time inside qemu In-reply-to: <200612291810.41992.paul@codesourcery.com> Message-id: <46238B18.1080308@uab.cat> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Fj+n7Yq3GqraCwej1k12ZQ)" References: <459540A8.8020209@uab.cat> <200612291743.05983.paul@codesourcery.com> <45955621.2030301@uab.cat> <200612291810.41992.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --Boundary_(ID_Fj+n7Yq3GqraCwej1k12ZQ) Content-type: multipart/alternative; boundary="Boundary_(ID_WHStbwH6Z88wedHZVu9UEA)" --Boundary_(ID_WHStbwH6Z88wedHZVu9UEA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE That's true, and I don't care about it. I'd like to get a method to stop/start time inside qemu in order to simulate execution of large pieces of hw out of qemu (look at qemu-systemc project). If qemu is freeze meanwhile a systemc simulation is in progress (simulating a HW device of system), time should be freeze also. In this way, execution time of a program inside qemu should appear shorter when using accelerator HW than only SW application. I know th= ese times are not reals, but it should be enough to estimate correctness = and execution time on real platforms. Does a way to stop/start time inside qemu? Thanks, M=E0rius En/na Paul Brook ha escrit: > On Friday 29 December 2006 17:53, M=E0rius Mont=F3n wrote: > =20 >> Hi, >> >> As I understand, OSes running inside qemu "have" notion of time: (= its >> date and time works, time(1) command works, etc.). >> My question is about how qemu manages time. I need to stop and sta= rt >> again this "virtual-time". >> =20 > > qemu doesn't maintain virtual time, it just uses the real host time= . > > =20 >> I just tried with cpu_disable_ticks() and cpu_enable_ticks(). It s= eems >> to work partially: at least now system date and time are out of sy= nc.. >> =20 > > I suspect you'll find that for anything other than very coarse user= (ie. user=20 > stop/continue) these are effectively useless. > > Any benchmark/performance measurements you make inside qemu are mea= ningless.=20 > qemu performance bears no relation whatsoever to the performance= =20 > characteristics of real hardware. > > =20 > Paul > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > =20 --=20 M=E0rius Mont=F3n i Maci=E1n marius.monton@uab.cat http://cephis.uab.es Hardware Engineer CEPHIS Centre de Prototips i Solucions Hardware-Software Dep. Microelectr=F2nica i Sistemes Electr=F2nics ETSE - Universitat Aut=F2noma de Barcelona (UAB) =09Phone: +34 935 81= 3 534 Fax: +34 935 813 033 QC-2090D. ETSE. Campus UAB. 080193 Bellaterra --Boundary_(ID_WHStbwH6Z88wedHZVu9UEA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE That's true, and I don't care about it. I'd like to get a method to stop/start time inside qemu in order to simulate execution of large pieces of hw out of qemu (look at qemu-systemc project).
If qemu is freeze  meanwhile a systemc simulation is in progress (simulating a HW device of system), time should be freeze also.
In this way, execution time of a program inside qemu should appear shorter when using accelerator HW than only SW application. I know these times are not reals, but it should be enough to estimate correctness and execution time on real platforms.

Does a way to stop/start time inside qemu?

Thanks,

Màrius

En/na Paul Brook ha escrit: 
On Friday 29 December 2006 17:53, Màrius Mont=
ón wrote:
  
Hi,

As I understand, OSes running inside qemu "have" notion of time: (its
date and time works, time(1) command works, etc.).
My question is about how qemu manages time. I need to stop and start
again this "virtual-time".
    

qemu doesn't maintain virtual time, it just uses the real host time.

  
I just tried with cpu_disable_ticks() and cpu_enab=
le_ticks(). It seems
to work partially: at least now system date and time are out of sync.=
.
    

I suspect you'll find that for anything other than very coarse user (=
ie. user=20
stop/continue) these are effectively useless.

Any benchmark/performance measurements you make inside qemu are meani=
ngless.=20
qemu performance bears no relation whatsoever to the performance=20
characteristics of real hardware.

  

Paul


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/q=
emu-devel

--
Màrius Montón i Macián   <= font color=3D"#00ffff">marius.monton@uab.cat   http://cephis.uab.es
Hardware Engine= er
 Centre de Proto= tips i Solucions Hardware-Software
Dep. Microelectrònica i Sistemes Electrònics
ETSE - Universitat Autònoma de Barcelona (UAB) = 		Phone: +34 = 935 813 534
 Fax: +3= 4 935 813 033
 QC-2090= D. ETSE. Campus UAB.
 080193 Bellaterra
--Boundary_(ID_WHStbwH6Z88wedHZVu9UEA)-- --Boundary_(ID_Fj+n7Yq3GqraCwej1k12ZQ) Content-type: text/x-vcard; charset=utf-8; name=marius.monton.vcf Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: attachment; filename=marius.monton.vcf begin:vcard fn;quoted-printable:M=3DC3=3DA0rius Mont=3DC3=3DB3n n;quoted-printable;quoted-printable:Mont=3DC3=3DB3n;M=3DC3=3DA0rius org:CEPHIS-UAB adr:Campus de la Autonoma;;QC-2090D. ETSE;Bellaterra;Barcelona;08193;= Spain email;internet:marius.monton@uab.cat title:System Engineer tel;work:+34935813534 url:http://cephis.uab.cat version:2.1 end:vcard --Boundary_(ID_Fj+n7Yq3GqraCwej1k12ZQ)--