From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50889)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1YH69N-00061N-ES
	for qemu-devel@nongnu.org; Fri, 30 Jan 2015 02:37:58 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1YH69K-0006we-7h
	for qemu-devel@nongnu.org; Fri, 30 Jan 2015 02:37:57 -0500
Received: from goliath.siemens.de ([192.35.17.28]:43812)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1YH69J-0006wO-UZ
	for qemu-devel@nongnu.org; Fri, 30 Jan 2015 02:37:54 -0500
Message-ID: <54CB34CB.20805@siemens.com>
Date: Fri, 30 Jan 2015 08:37:47 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <20150129203728.6cb9271e@crunchbang> <54CABD0A.1090207@redhat.com>
In-Reply-To: <54CABD0A.1090207@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] QEMU and Real Time OS
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, =?windows-1252?Q?Marc_Mar=ED?= <marc.mari.barcelo@gmail.com>, qemu-devel <qemu-devel@nongnu.org>
Cc: =?windows-1252?Q?KONRAD_Fr=E9d=E9ric?= <fred.konrad@greensocs.com>, Marcelo Tosatti <mtosatti@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>

On 2015-01-30 00:06, Paolo Bonzini wrote:
>=20
>=20
> On 29/01/2015 20:37, Marc Mar=ED wrote:
>> Is this an expected behaviour? I can't see why.
>>
>> I'd like to know if there is a certain reason why it doesn't work. Or
>> if it should work and the problem is too much I/O overhead. Or any
>> other hint to understand it.
>=20
> It is due to latencies in the host.  You need at least to use preempt-r=
t
> kernels in the host as well.

That alone won't help much. You also need to fine-tune the guest to
avoid running into QEMU locks that continuously synchronizes the guest
on things like VGA or disk I/O emulation.

When using KVM, thus being able to run VCPUs widely independent of each
other and the device models, you need to push cyclictest on an isolated
second virtual CPU of the guest. Luiz and Marcelo can probably confirm
this based on their ongoing experiments.

With TCG, we would first of all have to make it true SMP and independent
of the I/O device lock. That's what Frederic is working on [1].

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/314406

--=20
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux