From: Richard Weinberger <richard@nod.at>
To: tavi purdila <tavi.purdila@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Hajime Tazaki <thehajime@gmail.com>,
linux-arch <linux-arch@vger.kernel.org>, cem <cem@freebsd.org>,
linux-um <linux-um@lists.infradead.org>,
retrage01 <retrage01@gmail.com>,
linux-kernel-library <linux-kernel-library@freelists.org>,
pscollins <pscollins@google.com>,
sigmaepsilon92 <sigmaepsilon92@gmail.com>,
liuyuan <liuyuan@google.com>,
anton ivanov <anton.ivanov@cambridgegreys.com>
Subject: Re: [RFC v2 17/37] lkl tools: host lib: virtio devices
Date: Tue, 26 Nov 2019 17:04:55 +0100 (CET) [thread overview]
Message-ID: <293078386.98317.1574784295793.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <CAMoF9u3LRC_NaVJzmKPc0+XBxhAqdhnr4-ZzY_ypwQEzUz78yQ@mail.gmail.com>
----- Ursprüngliche Mail -----
> Von: "tavi purdila" <tavi.purdila@gmail.com>
> An: "Johannes Berg" <johannes@sipsolutions.net>
> CC: "richard" <richard@nod.at>, "Hajime Tazaki" <thehajime@gmail.com>, "linux-arch" <linux-arch@vger.kernel.org>, "cem"
> <cem@freebsd.org>, "linux-um" <linux-um@lists.infradead.org>, "retrage01" <retrage01@gmail.com>, "linux-kernel-library"
> <linux-kernel-library@freelists.org>, "pscollins" <pscollins@google.com>, "sigmaepsilon92" <sigmaepsilon92@gmail.com>,
> "liuyuan" <liuyuan@google.com>
> Gesendet: Dienstag, 26. November 2019 11:42:01
> Betreff: Re: [RFC v2 17/37] lkl tools: host lib: virtio devices
> On Tue, Nov 26, 2019 at 12:16 PM Johannes Berg
> <johannes@sipsolutions.net> wrote:
>>
>> On Tue, 2019-11-26 at 11:09 +0100, Richard Weinberger wrote:
>> > ----- Ursprüngliche 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 domain
>> > > socket internally to talk between the kernel (virtio_uml) and hypervisor
>> > > (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).
Can you please point out a little further why UML's net or block drivers
are not usable for LKL?
What is missing?
Performance numbers would be also nice to have.
Anton did great work on improving UML's drivers.
Thanks,
//richard
next prev parent reply other threads:[~2019-11-26 16:05 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1571798507.git.thehajime@gmail.com>
2019-10-25 21:34 ` [RFC PATCH 00/47] Unifying LKL into UML Richard Weinberger
2019-10-27 2:34 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 00/37] " Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 01/37] asm-generic: atomic64: allow using generic atomic64 on 64bit platforms Hajime Tazaki
2019-11-25 22:02 ` Richard Weinberger
2019-11-26 14:02 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 02/37] arch: add __SYSCALL_DEFINE_ARCH Hajime Tazaki
2019-11-25 22:02 ` Richard Weinberger
2019-11-27 4:15 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 03/37] lkl: architecture skeleton for Linux kernel library Hajime Tazaki
2019-11-25 22:00 ` Richard Weinberger
2019-11-26 11:42 ` Octavian Purdila
2019-11-26 14:17 ` Hajime Tazaki
2019-11-26 16:02 ` Richard Weinberger
2020-02-05 7:37 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 04/37] lkl: host interface Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 05/37] lkl: memory handling Hajime Tazaki
2019-11-25 22:10 ` Richard Weinberger
2020-02-05 7:38 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 06/37] lkl: kernel threads support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 07/37] lkl: interrupt support Hajime Tazaki
2019-11-25 22:13 ` Richard Weinberger
2020-02-05 7:38 ` Hajime Tazaki
2020-02-05 10:49 ` Anton Ivanov
2020-02-05 14:24 ` Hajime Tazaki
2020-02-18 8:18 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 08/37] lkl: system call interface and application API Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 09/37] lkl: timers, time and delay support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 10/37] lkl: memory mapped I/O support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 11/37] lkl: basic kernel console support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 12/37] lkl: initialization and cleanup Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 13/37] lkl: plug in the build system Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 14/37] lkl tools: skeleton for host side library, tests and tools Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 15/37] lkl tools: host lib: add utilities functions Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 16/37] lkl tools: host lib: memory mapped I/O helpers Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 17/37] lkl tools: host lib: virtio devices Hajime Tazaki
2019-11-25 22:07 ` Richard Weinberger
2019-11-26 8:43 ` Johannes Berg
2019-11-26 8:50 ` Richard Weinberger
2019-11-26 8:52 ` Johannes Berg
2019-11-26 10:09 ` Richard Weinberger
2019-11-26 10:16 ` Johannes Berg
2019-11-26 10:42 ` Octavian Purdila
2019-11-26 10:49 ` Anton Ivanov
2019-11-27 4:06 ` Hajime Tazaki
2019-11-26 16:04 ` Richard Weinberger [this message]
2019-11-27 4:08 ` Hajime Tazaki
2019-11-27 14:28 ` Richard Weinberger
2019-11-28 9:53 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 18/37] lkl tools: host lib: virtio block device Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 19/37] lkl tools: host lib: filesystem helpers Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 20/37] lkl tools: host lib: posix host operations Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 21/37] lkl tools: "boot" test Hajime Tazaki
2020-01-23 19:33 ` Brendan Higgins
2020-01-24 4:32 ` Hajime Tazaki
2020-03-02 19:51 ` Luis Chamberlain
2020-03-02 22:25 ` Brendan Higgins
2019-11-08 5:02 ` [RFC v2 22/37] lkl tools: tool that reads/writes to/from a filesystem image Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 23/37] lkl tools: tool that converts a filesystem image to tar Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 24/37] lkl tools: virtio: add network device support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 25/37] checkpatch: avoid showing BIT_ULL warnings for tools/ files Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 26/37] tools: Add the lkl host library to the common tools Makefile Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 27/37] lkl tools: add lklfuse Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 28/37] lkl: add system call hijack support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 29/37] lkl: add documentation Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 30/37] scripts: revert CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX patches Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 31/37] lkl: add support for Windows hosts Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 32/37] lkl tools: add support for Windows host Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 33/37] kallsyms: Add a config option to select section for kallsyms Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 34/37] lkl: Android ARM (arm/arm64) support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 35/37] um lkl: add CI tests Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 36/37] um: use lkl virtio_net_tap device as UML device Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 37/37] um: add lkl virtio-blk device Hajime Tazaki
2019-11-08 9:13 ` [RFC v2 00/37] Unifying LKL into UML Anton Ivanov
2019-11-08 11:17 ` Octavian Purdila
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=293078386.98317.1574784295793.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=anton.ivanov@cambridgegreys.com \
--cc=cem@freebsd.org \
--cc=johannes@sipsolutions.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel-library@freelists.org \
--cc=linux-um@lists.infradead.org \
--cc=liuyuan@google.com \
--cc=pscollins@google.com \
--cc=retrage01@gmail.com \
--cc=sigmaepsilon92@gmail.com \
--cc=tavi.purdila@gmail.com \
--cc=thehajime@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).