From: Avi Kivity <avi@redhat.com> To: Gregory Haskins <gregory.haskins@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com>, "Ira W. Snyder" <iws@ovro.caltech.edu>, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, mingo@elte.hu, linux-mm@kvack.org, akpm@linux-foundation.org, hpa@zytor.com, Rusty Russell <rusty@rustcorp.com.au>, s.hetze@linux-ag.com, alacrityvm-devel@lists.sourceforge.net Subject: Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server Date: Wed, 16 Sep 2009 11:23:12 +0300 [thread overview] Message-ID: <4AB0A070.1050400@redhat.com> (raw) In-Reply-To: <4AAFF437.7060100@gmail.com> On 09/15/2009 11:08 PM, Gregory Haskins wrote: > >> There's virtio-console, virtio-blk etc. None of these have kernel-mode >> servers, but these could be implemented if/when needed. >> > IIUC, Ira already needs at least ethernet and console capability. > > He's welcome to pick up the necessary code from qemu. >>> b) what do you suppose this protocol to aggregate the connections would >>> look like? (hint: this is what a vbus-connector does). >>> >>> >> You mean multilink? You expose the device as a multiqueue. >> > No, what I mean is how do you surface multiple ethernet and consoles to > the guests? For Ira's case, I think he needs at minimum at least one of > each, and he mentioned possibly having two unique ethernets at one point. > You instantiate multiple vhost-nets. Multiple ethernet NICs is a supported configuration for kvm. > His slave boards surface themselves as PCI devices to the x86 > host. So how do you use that to make multiple vhost-based devices (say > two virtio-nets, and a virtio-console) communicate across the transport? > I don't really see the difference between 1 and N here. > There are multiple ways to do this, but what I am saying is that > whatever is conceived will start to look eerily like a vbus-connector, > since this is one of its primary purposes ;) > I'm not sure if you're talking about the configuration interface or data path here. >>> c) how do you manage the configuration, especially on a per-board basis? >>> >>> >> pci (for kvm/x86). >> > Ok, for kvm understood (and I would also add "qemu" to that mix). But > we are talking about vhost's application in a non-kvm environment here, > right?. > > So if the vhost-X devices are in the "guest", They aren't in the "guest". The best way to look at it is - a device side, with a dma engine: vhost-net - a driver side, only accessing its own memory: virtio-net Given that Ira's config has the dma engine in the ppc boards, that's where vhost-net would live (the ppc boards acting as NICs to the x86 board, essentially). > and the x86 board is just > a slave...How do you tell each ppc board how many devices and what > config (e.g. MACs, etc) to instantiate? Do you assume that they should > all be symmetric and based on positional (e.g. slot) data? What if you > want asymmetric configurations (if not here, perhaps in a different > environment)? > I have no idea, that's for Ira to solve. If he could fake the PCI config space as seen by the x86 board, he would just show the normal pci config and use virtio-pci (multiple channels would show up as a multifunction device). Given he can't, he needs to tunnel the virtio config space some other way. >> Yes. virtio is really virtualization oriented. >> > I would say that its vhost in particular that is virtualization > oriented. virtio, as a concept, generally should work in physical > systems, if perhaps with some minor modifications. The biggest "limit" > is having "virt" in its name ;) > Let me rephrase. The virtio developers are virtualization oriented. If it works for non-virt applications, that's good, but not a design goal. -- error compiling committee.c: too many arguments to function
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com> To: Gregory Haskins <gregory.haskins@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com>, "Ira W. Snyder" <iws@ovro.caltech.edu>, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, mingo@elte.hu, linux-mm@kvack.org, akpm@linux-foundation.org, hpa@zytor.com, Rusty Russell <rusty@rustcorp.com.au>, s.hetze@linux-ag.com, alacrityvm-devel@lists.sourceforge.net Subject: Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server Date: Wed, 16 Sep 2009 11:23:12 +0300 [thread overview] Message-ID: <4AB0A070.1050400@redhat.com> (raw) In-Reply-To: <4AAFF437.7060100@gmail.com> On 09/15/2009 11:08 PM, Gregory Haskins wrote: > >> There's virtio-console, virtio-blk etc. None of these have kernel-mode >> servers, but these could be implemented if/when needed. >> > IIUC, Ira already needs at least ethernet and console capability. > > He's welcome to pick up the necessary code from qemu. >>> b) what do you suppose this protocol to aggregate the connections would >>> look like? (hint: this is what a vbus-connector does). >>> >>> >> You mean multilink? You expose the device as a multiqueue. >> > No, what I mean is how do you surface multiple ethernet and consoles to > the guests? For Ira's case, I think he needs at minimum at least one of > each, and he mentioned possibly having two unique ethernets at one point. > You instantiate multiple vhost-nets. Multiple ethernet NICs is a supported configuration for kvm. > His slave boards surface themselves as PCI devices to the x86 > host. So how do you use that to make multiple vhost-based devices (say > two virtio-nets, and a virtio-console) communicate across the transport? > I don't really see the difference between 1 and N here. > There are multiple ways to do this, but what I am saying is that > whatever is conceived will start to look eerily like a vbus-connector, > since this is one of its primary purposes ;) > I'm not sure if you're talking about the configuration interface or data path here. >>> c) how do you manage the configuration, especially on a per-board basis? >>> >>> >> pci (for kvm/x86). >> > Ok, for kvm understood (and I would also add "qemu" to that mix). But > we are talking about vhost's application in a non-kvm environment here, > right?. > > So if the vhost-X devices are in the "guest", They aren't in the "guest". The best way to look at it is - a device side, with a dma engine: vhost-net - a driver side, only accessing its own memory: virtio-net Given that Ira's config has the dma engine in the ppc boards, that's where vhost-net would live (the ppc boards acting as NICs to the x86 board, essentially). > and the x86 board is just > a slave...How do you tell each ppc board how many devices and what > config (e.g. MACs, etc) to instantiate? Do you assume that they should > all be symmetric and based on positional (e.g. slot) data? What if you > want asymmetric configurations (if not here, perhaps in a different > environment)? > I have no idea, that's for Ira to solve. If he could fake the PCI config space as seen by the x86 board, he would just show the normal pci config and use virtio-pci (multiple channels would show up as a multifunction device). Given he can't, he needs to tunnel the virtio config space some other way. >> Yes. virtio is really virtualization oriented. >> > I would say that its vhost in particular that is virtualization > oriented. virtio, as a concept, generally should work in physical > systems, if perhaps with some minor modifications. The biggest "limit" > is having "virt" in its name ;) > Let me rephrase. The virtio developers are virtualization oriented. If it works for non-virt applications, that's good, but not a design goal. -- error compiling committee.c: too many arguments to function -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-09-16 8:24 UTC|newest] Thread overview: 231+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <cover.1251388414.git.mst@redhat.com> 2009-08-27 16:06 ` [PATCHv5 1/3] mm: export use_mm/unuse_mm to modules Michael S. Tsirkin 2009-08-27 16:06 ` Michael S. Tsirkin 2009-08-27 16:06 ` Michael S. Tsirkin 2009-08-27 16:06 ` Michael S. Tsirkin 2009-08-28 15:31 ` Gregory Haskins 2009-08-28 15:31 ` Gregory Haskins 2009-08-27 16:07 ` [PATCHv5 2/3] mm: reduce atomic use on use_mm fast path Michael S. Tsirkin 2009-08-27 16:07 ` Michael S. Tsirkin 2009-08-27 16:07 ` Michael S. Tsirkin 2009-08-27 16:07 ` Michael S. Tsirkin 2009-08-27 16:07 ` [PATCHv5 3/3] vhost_net: a kernel-level virtio server Michael S. Tsirkin 2009-08-27 16:07 ` Michael S. Tsirkin 2009-08-27 16:07 ` Michael S. Tsirkin 2009-09-03 18:39 ` Ira W. Snyder 2009-09-03 18:39 ` Ira W. Snyder 2009-09-03 18:39 ` Ira W. Snyder 2009-09-07 10:15 ` Michael S. Tsirkin 2009-09-07 10:15 ` Michael S. Tsirkin 2009-09-07 10:15 ` Michael S. Tsirkin 2009-09-08 17:20 ` Ira W. Snyder 2009-09-08 17:20 ` Ira W. Snyder 2009-09-08 20:14 ` Michael S. Tsirkin 2009-09-08 20:14 ` Michael S. Tsirkin 2009-09-08 20:14 ` Michael S. Tsirkin 2009-09-11 15:17 ` Xin, Xiaohui 2009-09-11 15:17 ` Xin, Xiaohui 2009-09-13 5:46 ` Michael S. Tsirkin 2009-09-13 5:46 ` Michael S. Tsirkin 2009-09-14 5:57 ` Xin, Xiaohui 2009-09-14 5:57 ` Xin, Xiaohui 2009-09-14 5:57 ` Xin, Xiaohui 2009-09-14 5:57 ` Xin, Xiaohui 2009-09-14 7:05 ` Michael S. Tsirkin 2009-09-14 7:05 ` Michael S. Tsirkin 2009-09-14 7:05 ` Michael S. Tsirkin 2009-09-13 5:46 ` Michael S. Tsirkin 2009-09-11 15:17 ` Xin, Xiaohui 2009-09-11 16:00 ` Gregory Haskins 2009-09-11 16:14 ` Gregory Haskins 2009-09-11 16:14 ` Gregory Haskins 2009-09-13 12:01 ` Michael S. Tsirkin 2009-09-13 12:01 ` Michael S. Tsirkin 2009-09-13 12:01 ` Michael S. Tsirkin 2009-09-14 16:08 ` Gregory Haskins 2009-09-14 16:47 ` Michael S. Tsirkin 2009-09-14 16:47 ` Michael S. Tsirkin 2009-09-14 16:47 ` Michael S. Tsirkin 2009-09-14 19:14 ` Gregory Haskins 2009-09-15 12:35 ` Avi Kivity 2009-09-15 12:35 ` Avi Kivity 2009-09-15 12:35 ` Avi Kivity 2009-09-15 13:03 ` Gregory Haskins 2009-09-15 13:03 ` Gregory Haskins 2009-09-15 13:25 ` Avi Kivity 2009-09-15 13:25 ` Avi Kivity 2009-09-15 13:50 ` Gregory Haskins 2009-09-15 13:50 ` Gregory Haskins 2009-09-15 14:28 ` Michael S. Tsirkin 2009-09-15 14:28 ` Michael S. Tsirkin 2009-09-15 14:28 ` Michael S. Tsirkin 2009-09-15 15:03 ` Avi Kivity 2009-09-15 15:03 ` Avi Kivity 2009-09-15 15:03 ` Avi Kivity 2009-09-15 20:08 ` Gregory Haskins 2009-09-15 20:08 ` Gregory Haskins 2009-09-15 20:40 ` Michael S. Tsirkin 2009-09-15 20:40 ` Michael S. Tsirkin 2009-09-15 20:43 ` Gregory Haskins 2009-09-15 20:43 ` Gregory Haskins 2009-09-15 21:25 ` Michael S. Tsirkin 2009-09-15 21:25 ` Michael S. Tsirkin 2009-09-15 21:39 ` Gregory Haskins 2009-09-15 21:39 ` Gregory Haskins 2009-09-15 21:38 ` Michael S. Tsirkin 2009-09-15 21:38 ` Michael S. Tsirkin 2009-09-15 21:55 ` Gregory Haskins 2009-09-15 21:55 ` Gregory Haskins 2009-09-15 21:38 ` Michael S. Tsirkin 2009-09-16 14:57 ` Arnd Bergmann 2009-09-16 14:57 ` Arnd Bergmann 2009-09-16 15:13 ` Michael S. Tsirkin 2009-09-16 15:13 ` Michael S. Tsirkin 2009-09-16 15:13 ` Michael S. Tsirkin 2009-09-16 15:22 ` Arnd Bergmann 2009-09-16 15:22 ` Arnd Bergmann 2009-09-16 15:22 ` Arnd Bergmann 2009-09-16 16:08 ` Michael S. Tsirkin 2009-09-16 16:08 ` Michael S. Tsirkin 2009-09-16 16:08 ` Michael S. Tsirkin 2009-09-16 14:57 ` Arnd Bergmann 2009-09-15 21:25 ` Michael S. Tsirkin 2009-09-15 20:40 ` Michael S. Tsirkin 2009-09-16 8:23 ` Avi Kivity [this message] 2009-09-16 8:23 ` Avi Kivity 2009-09-16 11:44 ` Gregory Haskins 2009-09-16 13:05 ` Avi Kivity 2009-09-16 13:05 ` Avi Kivity 2009-09-16 14:10 ` Gregory Haskins 2009-09-16 15:59 ` Avi Kivity 2009-09-16 15:59 ` Avi Kivity 2009-09-16 15:59 ` Avi Kivity 2009-09-16 19:22 ` Gregory Haskins 2009-09-16 21:00 ` Avi Kivity 2009-09-16 21:00 ` Avi Kivity 2009-09-16 21:00 ` Avi Kivity 2009-09-17 3:11 ` Gregory Haskins 2009-09-17 7:49 ` Avi Kivity 2009-09-17 7:49 ` Avi Kivity 2009-09-17 7:49 ` Avi Kivity 2009-09-17 14:16 ` Javier Guerra 2009-09-17 14:16 ` Javier Guerra 2009-09-17 14:16 ` Javier Guerra 2009-09-21 21:43 ` Ira W. Snyder 2009-09-21 21:43 ` Ira W. Snyder 2009-09-21 21:43 ` Ira W. Snyder 2009-09-22 9:43 ` Avi Kivity 2009-09-22 9:43 ` Avi Kivity 2009-09-22 9:43 ` Avi Kivity 2009-09-22 15:25 ` Ira W. Snyder 2009-09-22 15:25 ` Ira W. Snyder 2009-09-22 15:56 ` Avi Kivity 2009-09-22 15:56 ` Avi Kivity 2009-09-22 15:56 ` Avi Kivity 2009-09-22 15:25 ` Ira W. Snyder 2009-09-23 14:26 ` Gregory Haskins 2009-09-23 14:37 ` Avi Kivity 2009-09-23 14:37 ` Avi Kivity 2009-09-23 15:10 ` Gregory Haskins 2009-09-23 17:58 ` Gregory Haskins 2009-09-23 17:58 ` Gregory Haskins 2009-09-23 19:37 ` Avi Kivity 2009-09-23 19:37 ` Avi Kivity 2009-09-23 19:37 ` Avi Kivity 2009-09-23 21:15 ` Gregory Haskins 2009-09-23 21:15 ` Gregory Haskins 2009-09-24 7:18 ` Avi Kivity 2009-09-24 7:18 ` Avi Kivity 2009-09-24 18:03 ` Gregory Haskins 2009-09-24 18:03 ` Gregory Haskins 2009-09-25 8:22 ` Avi Kivity 2009-09-25 8:22 ` Avi Kivity 2009-09-25 21:32 ` Gregory Haskins 2009-09-27 9:43 ` Avi Kivity 2009-09-27 9:43 ` Avi Kivity 2009-09-27 9:43 ` Avi Kivity 2009-09-30 20:04 ` Gregory Haskins 2009-10-01 8:34 ` Avi Kivity 2009-10-01 8:34 ` Avi Kivity 2009-10-01 8:34 ` Avi Kivity 2009-10-01 8:34 ` Avi Kivity 2009-10-01 9:28 ` Michael S. Tsirkin 2009-10-01 9:28 ` Michael S. Tsirkin 2009-10-01 9:28 ` Michael S. Tsirkin 2009-10-01 19:24 ` Gregory Haskins 2009-10-03 10:00 ` Avi Kivity 2009-10-03 10:00 ` Avi Kivity 2009-10-03 10:00 ` Avi Kivity 2009-10-01 19:24 ` Gregory Haskins 2009-09-30 20:04 ` Gregory Haskins 2009-09-25 21:32 ` Gregory Haskins 2009-09-25 8:22 ` Avi Kivity 2009-09-24 19:27 ` Ira W. Snyder 2009-09-24 19:27 ` Ira W. Snyder 2009-09-24 19:27 ` Ira W. Snyder 2009-09-25 7:43 ` Avi Kivity 2009-09-25 7:43 ` Avi Kivity 2009-09-25 7:43 ` Avi Kivity 2009-09-24 7:18 ` Avi Kivity 2009-09-24 8:03 ` Avi Kivity 2009-09-24 8:03 ` Avi Kivity 2009-09-24 8:03 ` Avi Kivity 2009-09-24 18:04 ` Gregory Haskins 2009-09-24 18:04 ` Gregory Haskins 2009-09-23 15:10 ` Gregory Haskins 2009-09-23 14:37 ` Avi Kivity 2009-09-23 14:26 ` Gregory Haskins 2009-09-17 3:11 ` Gregory Haskins 2009-09-16 19:22 ` Gregory Haskins 2009-09-17 3:57 ` Michael S. Tsirkin 2009-09-17 3:57 ` Michael S. Tsirkin 2009-09-17 3:57 ` Michael S. Tsirkin 2009-09-17 4:13 ` Gregory Haskins 2009-09-17 4:13 ` Gregory Haskins 2009-09-16 14:10 ` Gregory Haskins 2009-09-16 14:10 ` Gregory Haskins 2009-09-16 13:05 ` Avi Kivity 2009-09-16 11:44 ` Gregory Haskins 2009-09-16 8:23 ` Avi Kivity 2009-09-15 13:25 ` Avi Kivity 2009-09-14 19:14 ` Gregory Haskins 2009-09-15 12:32 ` Avi Kivity 2009-09-15 12:32 ` Avi Kivity 2009-09-15 12:32 ` Avi Kivity 2009-09-14 16:53 ` Michael S. Tsirkin 2009-09-14 16:53 ` Michael S. Tsirkin 2009-09-14 16:53 ` Michael S. Tsirkin 2009-09-14 19:28 ` Gregory Haskins 2009-09-14 19:28 ` Gregory Haskins 2009-09-14 16:08 ` Gregory Haskins 2009-09-11 16:00 ` Gregory Haskins 2009-09-08 17:20 ` Ira W. Snyder 2009-09-25 17:01 ` Ira W. Snyder 2009-09-25 17:01 ` Ira W. Snyder 2009-09-25 17:01 ` Ira W. Snyder 2009-09-27 7:43 ` Michael S. Tsirkin 2009-09-27 7:43 ` Michael S. Tsirkin 2009-09-27 7:43 ` Michael S. Tsirkin 2009-08-27 16:07 ` Michael S. Tsirkin [not found] <E88DD564E9DC5446A76B2B47C3BCCA150219600F9B@pdsmsx503.ccr.corp.intel.com> 2009-08-31 11:42 ` Xin, Xiaohui 2009-08-31 11:42 ` Xin, Xiaohui 2009-08-31 11:42 ` Xin, Xiaohui 2009-08-31 15:23 ` Arnd Bergmann 2009-08-31 15:23 ` Arnd Bergmann 2009-09-01 14:58 ` Xin, Xiaohui 2009-09-01 14:58 ` Xin, Xiaohui 2009-09-01 14:58 ` Xin, Xiaohui 2009-08-31 15:23 ` Arnd Bergmann 2009-08-31 17:52 ` Avi Kivity 2009-08-31 17:52 ` Avi Kivity 2009-08-31 21:56 ` Anthony Liguori 2009-08-31 21:56 ` Anthony Liguori 2009-08-31 21:56 ` Anthony Liguori 2009-09-01 15:37 ` Xin, Xiaohui 2009-09-01 15:37 ` Xin, Xiaohui 2009-09-01 15:37 ` Xin, Xiaohui 2009-09-01 5:04 ` Xin, Xiaohui 2009-09-01 5:04 ` Xin, Xiaohui 2009-09-01 5:04 ` Xin, Xiaohui 2009-08-31 17:52 ` Avi Kivity 2009-08-31 11:42 ` Xin, Xiaohui 2009-08-31 11:42 ` Xin, Xiaohui
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=4AB0A070.1050400@redhat.com \ --to=avi@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=alacrityvm-devel@lists.sourceforge.net \ --cc=gregory.haskins@gmail.com \ --cc=hpa@zytor.com \ --cc=iws@ovro.caltech.edu \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mingo@elte.hu \ --cc=mst@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=rusty@rustcorp.com.au \ --cc=s.hetze@linux-ag.com \ --cc=virtualization@lists.linux-foundation.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.