From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f196.google.com ([209.85.214.196]:32839 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726525AbfK0EIR (ORCPT ); Tue, 26 Nov 2019 23:08:17 -0500 Received: by mail-pl1-f196.google.com with SMTP id ay6so9168396plb.0 for ; Tue, 26 Nov 2019 20:08:16 -0800 (PST) Date: Wed, 27 Nov 2019 13:08:11 +0900 Message-ID: From: Hajime Tazaki Subject: Re: [RFC v2 17/37] lkl tools: host lib: virtio devices In-Reply-To: <293078386.98317.1574784295793.JavaMail.zimbra@nod.at> References: <1662825264.98055.1574758225905.JavaMail.zimbra@nod.at> <4ebb14dc67ccb70543617ce1f7066f3f27cd11a8.camel@sipsolutions.net> <243342257.98153.1574762974057.JavaMail.zimbra@nod.at> <98acf77a7c6f6cba7f76c12a850ac2929b9e5a48.camel@sipsolutions.net> <293078386.98317.1574784295793.JavaMail.zimbra@nod.at> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: linux-arch-owner@vger.kernel.org List-ID: To: richard@nod.at Cc: tavi.purdila@gmail.com, johannes@sipsolutions.net, linux-arch@vger.kernel.org, cem@freebsd.org, linux-um@lists.infradead.org, retrage01@gmail.com, linux-kernel-library@freelists.org, pscollins@google.com, sigmaepsilon92@gmail.com, liuyuan@google.com, anton.ivanov@cambridgegreys.com Hello, On Wed, 27 Nov 2019 01:04:55 +0900, Richard Weinberger wrote: > >> On Tue, 2019-11-26 at 11:09 +0100, Richard Weinberger wrote: > >> > ----- Urspr=FCngliche Mail ----- > >> > > > My point is that UML and LKL should try to do use the same conce= pt/code > >> > > > regarding virtio. At the end of day both use virtual devices whi= ch use > >> > > > facilities from the host. > >> > > > If this is really not possible it needs a good explanation. > >> > > > >> > > I think it isn't possible, unless you use vhost-user over a unix d= omain > >> > > socket internally to talk between the kernel (virtio_uml) and hype= rvisor > >> > > (device) components. > >> > > > >> > > In virtio_uml, the device implementation is assumed to be a separa= te > >> > > process with a vhost-user connection. Here in LKL, the virtio devi= ce is > >> > > part of the "hypervisor", i.e. in the same process. > >> > > >> > Exactly, currently UML and LKL solve same things differently, but do= we need to? > >> > >> It's not the same thing though :-) > >> > >> UML right now doesn't have or support virtio devices in the built-in > >> hypervisor, what we wanted to use virtio for was explicitly for the > >> vhost-user devices. > >> > >> LKL clearly wants to have device implementations in the hypervisor, > >> perhaps for networking or console etc.? That _might_ be useful since it > >> makes the device implementation more general, unlike the UML approach > >> where all devices come with a kernel- and user-side and are special > >> drivers in the kernel, vs. general virtio drivers. > >> > >=20 > > That is correct. Initially we used the same UML model, with dedicated > > drivers for LKL, and later switched to using the built-in virtio > > drivers (so far for network and block devices). >=20 > Can you please point out a little further why UML's net or block drivers > are not usable for LKL? I think we can do it (but need to check). LKL may use UML's drivers, and UML can also use LKL's devices/drivers (as my 36/37 and 37/37 patches do, though the patches has no careful consideration on IRQ handling). > What is missing? As Anton mentioned, the IRQ handling needs to be considered in LKL, at least. I need to check but there might be other factors. > Performance numbers would be also nice to have. > Anton did great work on improving UML's drivers. Performance improve techniques (bulk operations, offload, etc) are also applicable to both. As UML can do, LKL can TSO/csum offload with configured virtio-net devices. -- Hajime