From: Hajime Tazaki <thehajime@gmail.com>
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
Subject: Re: [RFC v2 17/37] lkl tools: host lib: virtio devices
Date: Wed, 27 Nov 2019 13:08:11 +0900 [thread overview]
Message-ID: <m2wobmq7v8.wl-thehajime@gmail.com> (raw)
In-Reply-To: <293078386.98317.1574784295793.JavaMail.zimbra@nod.at>
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ü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?
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
next prev parent reply other threads:[~2019-11-27 4:08 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
2019-11-27 4:08 ` Hajime Tazaki [this message]
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=m2wobmq7v8.wl-thehajime@gmail.com \
--to=thehajime@gmail.com \
--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=richard@nod.at \
--cc=sigmaepsilon92@gmail.com \
--cc=tavi.purdila@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).