From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f193.google.com ([209.85.214.193]:38524 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726525AbfK0EG2 (ORCPT ); Tue, 26 Nov 2019 23:06:28 -0500 Received: by mail-pl1-f193.google.com with SMTP id o8so4791997pls.5 for ; Tue, 26 Nov 2019 20:06:28 -0800 (PST) Date: Wed, 27 Nov 2019 13:06:22 +0900 Message-ID: From: Hajime Tazaki Subject: Re: [RFC v2 17/37] lkl tools: host lib: virtio devices In-Reply-To: References: <1531c5f16a00b608635c9a62fa3951807075f950.1573179553.git.thehajime@gmail.com> <1662825264.98055.1574758225905.JavaMail.zimbra@nod.at> <4ebb14dc67ccb70543617ce1f7066f3f27cd11a8.camel@sipsolutions.net> <243342257.98153.1574762974057.JavaMail.zimbra@nod.at> <98acf77a7c6f6cba7f76c12a850ac2929b9e5a48.camel@sipsolutions.net> 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: anton.ivanov@kot-begemot.co.uk Cc: tavi.purdila@gmail.com, johannes@sipsolutions.net, linux-arch@vger.kernel.org, cem@freebsd.org, richard@nod.at, linux-um@lists.infradead.org, retrage01@gmail.com, linux-kernel-library@freelists.org, pscollins@google.com, sigmaepsilon92@gmail.com, liuyuan@google.com On Tue, 26 Nov 2019 19:49:48 +0900, Anton Ivanov wrote: >=20 >=20 >=20 > On 26/11/2019 10:42, Octavian Purdila wrote: > > On Tue, Nov 26, 2019 at 12:16 PM Johannes Berg > > wrote: > >>=20 > >> 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 concept/= code > >>>>> regarding virtio. At the end of day both use virtual devices which = use > >>>>> facilities from the host. > >>>>> If this is really not possible it needs a good explanation. > >>>>=20 > >>>> I think it isn't possible, unless you use vhost-user over a unix dom= ain > >>>> socket internally to talk between the kernel (virtio_uml) and hyperv= isor > >>>> (device) components. > >>>>=20 > >>>> In virtio_uml, the device implementation is assumed to be a separate > >>>> process with a vhost-user connection. Here in LKL, the virtio device= is > >>>> part of the "hypervisor", i.e. in the same process. > >>>=20 > >>> Exactly, currently UML and LKL solve same things differently, but do = we need to? > >>=20 > >> It's not the same thing though :-) > >>=20 > >> 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. > >>=20 > >> 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 > >=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 > >> Now, arguably, since UML has all these already a combined UML/LKL > >> doesn't actually *need* any virtio devices, since all (or at least mos= t) > >> of the things that could be covered by virtio today are already covered > >> by UML devices (block, net, console, random). > >>=20 > >> I'd probably say then that this can be removed from an initial "minimum > >> viable product" of LKL, since once merged with UML you get the devices > >> from that. Later, we could decide that UML devices actually are better > >> done as virtio, and support something like this. > >>=20 > >=20 > > I agree, I think it make sense to drop these since the problem of > > dedicated vs generic / virtio drivers are orthogonal with regard to > > UML and LKL unification and can later be worked on. >=20 > This brings us back to the interrupt controller as noted by Richard earli= er. >=20 > UML devices are heavily dependent on the file io as an IRQ trigger > paradigm and they need an interrupt controller which has an IO event > feed into it. I did not see that in LKL on first read. Indeed, the current interrupt model in LKL is not directly associated with file IO events delivered by epoll family as UML does. Instead, calling lkl_trigger_irq() at places will trigger an interrupt in the LKL case so, we need to adapt somehow if LKL uses UML devices. > So as a first step we should get it to work with existing UML IRQ > controller and whatever incremental patches are needed on top of that. I understand and agree on your comments by all of you. If implementing LKL with current/existing UML devices is the right direction, I would go and try to test this approach to verify if this is doable. -- Hajime 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 1iZob4-0007pr-9i for linux-um@lists.infradead.org; Wed, 27 Nov 2019 04:06:38 +0000 Received: by mail-pl1-x642.google.com with SMTP id d7so9148703pls.3 for ; Tue, 26 Nov 2019 20:06:28 -0800 (PST) Date: Wed, 27 Nov 2019 13:06:22 +0900 Message-ID: From: Hajime Tazaki Subject: Re: [RFC v2 17/37] lkl tools: host lib: virtio devices In-Reply-To: References: <1531c5f16a00b608635c9a62fa3951807075f950.1573179553.git.thehajime@gmail.com> <1662825264.98055.1574758225905.JavaMail.zimbra@nod.at> <4ebb14dc67ccb70543617ce1f7066f3f27cd11a8.camel@sipsolutions.net> <243342257.98153.1574762974057.JavaMail.zimbra@nod.at> <98acf77a7c6f6cba7f76c12a850ac2929b9e5a48.camel@sipsolutions.net> 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: anton.ivanov@kot-begemot.co.uk Cc: linux-arch@vger.kernel.org, cem@freebsd.org, tavi.purdila@gmail.com, richard@nod.at, 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 On Tue, 26 Nov 2019 19:49:48 +0900, Anton Ivanov wrote: > = > = > = > On 26/11/2019 10:42, Octavian Purdila wrote: > > On Tue, Nov 26, 2019 at 12:16 PM Johannes Berg > > 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 concept/= code > >>>>> regarding virtio. At the end of day both use virtual devices which = 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 dom= ain > >>>> socket internally to talk between the kernel (virtio_uml) and hyperv= isor > >>>> (device) components. > >>>> = > >>>> In virtio_uml, the device implementation is assumed to be a separate > >>>> process with a vhost-user connection. Here in LKL, the virtio device= 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). > > = > >> Now, arguably, since UML has all these already a combined UML/LKL > >> doesn't actually *need* any virtio devices, since all (or at least mos= t) > >> of the things that could be covered by virtio today are already covered > >> by UML devices (block, net, console, random). > >> = > >> I'd probably say then that this can be removed from an initial "minimum > >> viable product" of LKL, since once merged with UML you get the devices > >> from that. Later, we could decide that UML devices actually are better > >> done as virtio, and support something like this. > >> = > > = > > I agree, I think it make sense to drop these since the problem of > > dedicated vs generic / virtio drivers are orthogonal with regard to > > UML and LKL unification and can later be worked on. > = > This brings us back to the interrupt controller as noted by Richard earli= er. > = > UML devices are heavily dependent on the file io as an IRQ trigger > paradigm and they need an interrupt controller which has an IO event > feed into it. I did not see that in LKL on first read. Indeed, the current interrupt model in LKL is not directly associated with file IO events delivered by epoll family as UML does. Instead, calling lkl_trigger_irq() at places will trigger an interrupt in the LKL case so, we need to adapt somehow if LKL uses UML devices. > So as a first step we should get it to work with existing UML IRQ > controller and whatever incremental patches are needed on top of that. I understand and agree on your comments by all of you. If implementing LKL with current/existing UML devices is the right direction, I would go and try to test this approach to verify if this is doable. -- Hajime _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um