From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyG3a-0000q7-Dj for qemu-devel@nongnu.org; Fri, 29 May 2015 04:54:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YyG3W-0006we-DN for qemu-devel@nongnu.org; Fri, 29 May 2015 04:54:22 -0400 Received: from zimbra3.corp.accelance.fr ([2001:4080:204::2:8]:52258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyG3W-0006wY-7H for qemu-devel@nongnu.org; Fri, 29 May 2015 04:54:18 -0400 Date: Fri, 29 May 2015 10:54:13 +0200 (CEST) From: Victor Clement Message-ID: <926526427.739772.1432889652962.JavaMail.root@openwide.fr> In-Reply-To: <5565BE27.4070202@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: =?utf-8?Q?fran=C3=A7ois?= Guerret , Paolo Bonzini , Julien Viard de Galbert ----- Mail original ----- > De: "Paolo Bonzini" > =C3=80: "Victor CLEMENT" , qemu-devel@nongnu.= org > Cc: "francois guerret" > Envoy=C3=A9: Mercredi 27 Mai 2015 14:52:55 > Objet: Re: [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode >=20 > [...] Or are there other cases besides RTC devices? >=20 > Paolo >=20 For the normal use case of QEmu, No. But we want to use QEmu to test hard real time application against simulated external stimuli. So basically, Qemu will be used to run the embedded software, but the external interfaces (GPIO, SPI, CAN bus...) will be controlled by a basic simulator playing some predefined scenario. Also we will record some traces to validate the behavior. The scenario engine and the trace recorder will need to use the virtual clock, so that all dates are based on the same clock. Again, at this stage we think this scenario engine will not be generic so the code will not be ready for integration in qemu. Our goal is to be able to run a real time application (under an RTOS) and test it with some scenario : For instance our application could monitor a GPIO and send a specific CAN frame within a specified delay. In that case, the scenario will control the GPIO input and the recorder will trace both the GPIO and the CAN bus. So by analysing the traces we will be able to check that the software meets its timing constraints. This example is simple but still shows the kind of problems we want to solve. I hope this enlighten you on our motivations. Best regards, Victor Cl=C3=A9ment & Julien Viard de Galbert