From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iZoci-0007zx-Sv for linux-um@lists.infradead.org; Wed, 27 Nov 2019 04:08:18 +0000 Received: by mail-pl1-x642.google.com with SMTP id q16so4959552plr.10 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") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: richard@nod.at Cc: linux-arch@vger.kernel.org, cem@freebsd.org, tavi.purdila@gmail.com, linux-um@lists.infradead.org, retrage01@gmail.com, pscollins@google.com, linux-kernel-library@freelists.org, johannes@sipsolutions.net, 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. > >> > > = > > 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). > = > 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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um