From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH90T-000236-1h for qemu-devel@nongnu.org; Fri, 30 Jan 2015 05:40:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YH90P-0007no-RR for qemu-devel@nongnu.org; Fri, 30 Jan 2015 05:40:56 -0500 Received: from mail-wg0-x22e.google.com ([2a00:1450:400c:c00::22e]:48423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH90P-0007nk-KL for qemu-devel@nongnu.org; Fri, 30 Jan 2015 05:40:53 -0500 Received: by mail-wg0-f46.google.com with SMTP id l2so26121577wgh.5 for ; Fri, 30 Jan 2015 02:40:53 -0800 (PST) Date: Fri, 30 Jan 2015 11:40:47 +0100 From: Marc =?UTF-8?B?TWFyw60=?= Message-ID: <20150130114047.43a4923e@crunchbang> In-Reply-To: <54CB5EB5.7050902@greensocs.com> References: <20150129203728.6cb9271e@crunchbang> <54CABD0A.1090207@redhat.com> <54CB34CB.20805@siemens.com> <20150130112644.3ab44d84@crunchbang> <54CB5EB5.7050902@greensocs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] QEMU and Real Time OS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Frederic Konrad Cc: Marcelo Tosatti , Jan Kiszka , Luiz Capitulino , qemu-devel , Paolo Bonzini El Fri, 30 Jan 2015 11:36:37 +0100 Frederic Konrad escribi=C3=B3: > On 30/01/2015 11:26, Marc Mar=C3=AD wrote: > > El Fri, 30 Jan 2015 08:37:47 +0100 > > Jan Kiszka escribi=C3=B3: > >> On 2015-01-30 00:06, Paolo Bonzini wrote: > >>> > >>> On 29/01/2015 20:37, Marc Mar=C3=AD 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. > >>> It is due to latencies in the host. You need at least to use > >>> preempt-rt 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 > >> > > Thanks for the answers. I think I'm stuck with ARM926, which I > > think is not prepared for SMP. I'll have to look if I can use > > Cortex for my experiments. > > > > I'll continue interested with the improvements for RT on TCG, but > > for the moment I'll go to work on real harware, even though is > > easier to run and debug on an emulator. > > > > Thanks > > Marc > Hi Marc, >=20 > I think the important point here is "TCG thread independent of the > I/O device lock". > I need it for multithread TCG but that doesn't mean you need an SMP > guest platform for that. >=20 > Fred >=20 I read too fast, sorry. What has to be multicore is the host, so the I/O can run independently of the TCG. But the guest can be multi- or uni-core. Marc