From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E1D8C282CE for ; Wed, 22 May 2019 13:34:01 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4603720879 for ; Wed, 22 May 2019 13:34:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4603720879 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kot-begemot.co.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([127.0.0.1]:43335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTRNY-000695-F8 for qemu-devel@archiver.kernel.org; Wed, 22 May 2019 09:34:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTRIR-0002z7-T6 for qemu-devel@nongnu.org; Wed, 22 May 2019 09:28:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hTRIP-0007Vq-FN for qemu-devel@nongnu.org; Wed, 22 May 2019 09:28:43 -0400 Received: from ivanoab6.miniserver.com ([5.153.251.140]:57232 helo=www.kot-begemot.co.uk) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hTRIO-0007RA-OM for qemu-devel@nongnu.org; Wed, 22 May 2019 09:28:41 -0400 Received: from [192.168.17.6] (helo=jain.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hTRIH-00045N-3j; Wed, 22 May 2019 13:28:33 +0000 Received: from jain.kot-begemot.co.uk ([192.168.3.3]) by jain.kot-begemot.co.uk with esmtp (Exim 4.89) (envelope-from ) id 1hTRIE-0003iF-IX; Wed, 22 May 2019 14:28:32 +0100 To: Johannes Berg , linux-um@lists.infradead.org, virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org References: <0952696452f5ff4e38d2417029243fc60efa33d6.camel@sipsolutions.net> From: Anton Ivanov Message-ID: Date: Wed, 22 May 2019 14:28:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <0952696452f5ff4e38d2417029243fc60efa33d6.camel@sipsolutions.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Clacks-Overhead: GNU Terry Pratchett X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 5.153.251.140 Subject: Re: [Qemu-devel] custom virt-io support (in user-mode-linux) X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 22/05/2019 14:02, Johannes Berg wrote: > Hi, > > While my main interest is mostly in UML right now [1] I've CC'ed the > qemu and virtualization lists because something similar might actually > apply to other types of virtualization. > > I'm thinking about adding virt-io support to UML, but the tricky part is > that while I want to use the virt-io basics (because it's a nice > interface from the 'inside'), I don't actually want the stock drivers > that are part of the kernel now (like virtio-net etc.) but rather > something that integrates with wifi (probably building on hwsim). > > The 'inside' interfaces aren't really a problem - just have a specific > device ID for this, and then write a normal virtio kernel driver for it. > > The 'outside' interfaces are where my thinking breaks down right now. > > Looking at lkl, the outside is just all implemented in lkl as code that > gets linked to the library, so in UML terms it'd just be extra 'outside' > code like the timer handling or other netdev stuff we have today. > Looking at qemu, it's of course also implemented there, and then > interfaces with the real network, console abstraction, etc. > > However, like I said above, I really need something very custom and not > likely to make it upstream to any project (because what point is that if > you cannot connect to the rest of the environment I'm building), so I'm > thinking that perhaps it should be possible to write an abstract > 'outside' that lets you interact with it really from out-of-process? > Perhaps through some kind of shared memory segment? I think that gets > tricky with virt-io doing DMA (I think it does?) though, so that part > would have to be implemented directly and not out-of-process? > > But really that's why I'm asking - is there a better way than to just > link the device-side virt-io code into the same binary (be it lkl lib, > uml binary, qemu binary)? > > Thanks, > johannes > > [1] Actually, I've considered using qemu, but it doesn't have > virtualized time and doesn't seem to support TSC virtualization. I guess > I could remove TSC from the guest CPU and add a virtualized HPET, but > I've yet to convince myself this works - on UML I made virtual time as a > prototype already: > https://patchwork.ozlabs.org/patch/1095814/ > (though my real goal isn't to just skip time forward when the host goes > idle, it's to sync with other simulated components) > > > _______________________________________________ > linux-um mailing list > linux-um@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-um > I have looked at using virtio semantics in UML in the past around the point when I wanted to make the recvmmsg/sendmmsg vector drivers common in UML and QEMU. It is certainly possible, I went for the native approach at the end though. -- Anton R. Ivanov https://www.kot-begemot.co.uk/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ivanoab6.miniserver.com ([5.153.251.140] helo=www.kot-begemot.co.uk) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hTRIO-0000HP-Hv for linux-um@lists.infradead.org; Wed, 22 May 2019 13:28:42 +0000 Subject: Re: custom virt-io support (in user-mode-linux) References: <0952696452f5ff4e38d2417029243fc60efa33d6.camel@sipsolutions.net> From: Anton Ivanov Message-ID: Date: Wed, 22 May 2019 14:28:30 +0100 MIME-Version: 1.0 In-Reply-To: <0952696452f5ff4e38d2417029243fc60efa33d6.camel@sipsolutions.net> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Johannes Berg , linux-um@lists.infradead.org, virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org On 22/05/2019 14:02, Johannes Berg wrote: > Hi, > > While my main interest is mostly in UML right now [1] I've CC'ed the > qemu and virtualization lists because something similar might actually > apply to other types of virtualization. > > I'm thinking about adding virt-io support to UML, but the tricky part is > that while I want to use the virt-io basics (because it's a nice > interface from the 'inside'), I don't actually want the stock drivers > that are part of the kernel now (like virtio-net etc.) but rather > something that integrates with wifi (probably building on hwsim). > > The 'inside' interfaces aren't really a problem - just have a specific > device ID for this, and then write a normal virtio kernel driver for it. > > The 'outside' interfaces are where my thinking breaks down right now. > > Looking at lkl, the outside is just all implemented in lkl as code that > gets linked to the library, so in UML terms it'd just be extra 'outside' > code like the timer handling or other netdev stuff we have today. > Looking at qemu, it's of course also implemented there, and then > interfaces with the real network, console abstraction, etc. > > However, like I said above, I really need something very custom and not > likely to make it upstream to any project (because what point is that if > you cannot connect to the rest of the environment I'm building), so I'm > thinking that perhaps it should be possible to write an abstract > 'outside' that lets you interact with it really from out-of-process? > Perhaps through some kind of shared memory segment? I think that gets > tricky with virt-io doing DMA (I think it does?) though, so that part > would have to be implemented directly and not out-of-process? > > But really that's why I'm asking - is there a better way than to just > link the device-side virt-io code into the same binary (be it lkl lib, > uml binary, qemu binary)? > > Thanks, > johannes > > [1] Actually, I've considered using qemu, but it doesn't have > virtualized time and doesn't seem to support TSC virtualization. I guess > I could remove TSC from the guest CPU and add a virtualized HPET, but > I've yet to convince myself this works - on UML I made virtual time as a > prototype already: > https://patchwork.ozlabs.org/patch/1095814/ > (though my real goal isn't to just skip time forward when the host goes > idle, it's to sync with other simulated components) > > > _______________________________________________ > linux-um mailing list > linux-um@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-um > I have looked at using virtio semantics in UML in the past around the point when I wanted to make the recvmmsg/sendmmsg vector drivers common in UML and QEMU. It is certainly possible, I went for the native approach at the end though. -- Anton R. Ivanov https://www.kot-begemot.co.uk/ _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um