Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
btw: Rusty, I tried to apply the new-io-lguest* patches and they failed to apply cleanly. What base repo do you use for that? Sorry, with all the movement of getting lguest in tree, those patches have rotted slightly (particularly the new-io-lguest-readwrite.patch which needs a complete rework). I've restored them now (well, they apply and compile again...) I tried to apply the series on 2.6.23-rc3 and it failed :( I tried to apply all the series (looks like virtio doesn't have the arch independent support) and only the the virtio patches broke in the lguest-desc patch. -- Dor. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
On Wed, 2007-08-15 at 00:52 -0700, Dor Laor wrote: If the above is followed, any enhancement will be appriciated. Since I am close, I will probably make at least one more v3 drop as is with the new lguest_bus inspired pvbus (with hotplug, etc). From there, we can (virtually) get together and figure out what can be used directly, what can be used in spirit, and what should be thrown away. Dor, I know you mentioned you wanted to go stepwise, but note that I *did* break it up into a series. I just delivered it all at once ;) But the fact is, I really need to do this stuff in-kernel so I am very much interested in getting the solution designed with that in mind from the get-go. So note that you will continue to see a series that is oriented to support both your userspace approach and my current in-kernel direction. (Note that my current series doesn't deal with the userspace side yet). Please point me to your current branch when it is available for me to look at. I'm looking forward to helping out here! Regards, -Greg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
On Wed, 2007-08-15 at 00:13 -0400, Gregory Haskins wrote: On Wed, 2007-08-15 at 06:58 +0300, Avi Kivity wrote: since it wants to be hypervisor agnostic, it cannot specify an ABI (as some already have ABIs, for example Xen). I see, and that is a good point. By only being an API, virtio can work over XenBus or any other ABI it wants. IOQ is an API *and* an ABI. While this doesnt preclude it from ever working on Xen, it does imply that you would need to add the IOQ ABI to the Xen infrastructure if you wanted to use it (at least, if you wanted to use it directly instead of doing some kind of funky queue-in-queue with IOQ on XenBus..yuk). I think I misspoke when I said this (it was up way to late for coherent thought ;) While what you said is true (virtio = API, IOQ = API+ABI) note that I believe both can be considered hypervisor agnostic. (That was a primary design goal of mine). All the hypervisor would need to do is write an ioq_mgr layer. Xen for instance, could use either hypercalls/interrupts directly like I do for the KVM implementation. Or it could use XenBus as a signaling transport. I am only bringing this up as a correction to my statement, not to try to sway someone in some kind of IOQ vs VirtIO debate. :) Regards, -Greg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
Since I am close, I will probably make at least one more v3 drop as is with the new lguest_bus inspired pvbus (with hotplug, etc). From there, we can (virtually) get together and figure out what can be used directly, what can be used in spirit, and what should be thrown away. Sure thing. Dor, I know you mentioned you wanted to go stepwise, but note that I *did* break it up into a series. I just delivered it all at once ;) The series is good, though personally I prefer to test each stage using live packets. Well, I recon the IOQ already tested and only the other mechanisms are new. But the fact is, I really need to do this stuff in-kernel so I am very much interested in getting the solution designed with that in mind from the get-go. So note that you will continue to see a series that is oriented to support both your userspace approach and my current in-kernel direction. (Note that my current series doesn't deal with the userspace side yet). Please point me to your current branch when it is available for me to look at. I'm looking forward to helping out here! Currently things at my end are a bit broken since I replaced the dma backend with a generic dma based on Rusty's code. Hope that it will work tomorrow. If you'll be quick enough you can rip the lguest_bus into a very light weight virtio_bus. Please keep it thin as possible, Rusty's code is 217 lines long, half of it comments. I'm planing to have a flexible use of this bus while one can either choose virtio_bus or pci bus. Regards, -Greg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
On Wed, 2007-08-15 at 15:37 -0700, Dor Laor wrote: If you'll be quick enough you can rip the lguest_bus into a very light weight virtio_bus. Please keep it thin as possible, Rusty's code is 217 lines long, half of it comments. I'm planing to have a flexible use of this bus while one can either choose virtio_bus or pci bus. Already done ;) Its not quite polished yet. I will send tomorrow. Currently it looks like this: arch/x86_64/Kconfig |2 drivers/Makefile |1 drivers/pvbus/Kconfig|7 +++ drivers/pvbus/Makefile |6 ++ drivers/pvbus/pvbus-driver.c | 89 +++ include/linux/pvbus.h| 55 ++ 6 files changed, 160 insertions(+) Of course its still IOQ oriented currently, but we can reconcile that when we get together. -Greg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
On Wed, 2007-08-15 at 00:52 -0700, Dor Laor wrote: btw: Rusty, I tried to apply the new-io-lguest* patches and they failed to apply cleanly. What base repo do you use for that? Sorry, with all the movement of getting lguest in tree, those patches have rotted slightly (particularly the new-io-lguest-readwrite.patch which needs a complete rework). I've restored them now (well, they apply and compile again...) Cheers, Rusty. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
Gregory Haskins wrote: This series incorporates all of v1 plus the following changes based on feedback to date: Are you positioning this as an alternative to virtio? If so, be aware that virtio is (a) mostly done (b) very well done. Can you describe what you are trying to achieve that virtio doesn't do? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
On Wed, 2007-08-15 at 05:50 +0300, Avi Kivity wrote: Gregory Haskins wrote: This series incorporates all of v1 plus the following changes based on feedback to date: Are you positioning this as an alternative to virtio? Absolutely not! I really just want to see a decent PV-IO solution working. When I originally started this project virtio didn't exist. And even recently I was under the impression that there was no implementation of virtio for KVM in existence. I just learned this morning that Dor is pretty close to getting something working, but that was news to me. If so, be aware that virtio is (a) mostly done (b) very well done. I would very much like to help make virtio work, which is really where I was going with this. My design is a little bit different so I was submitting it in case there was any ideas worth salvaging to be picked up by the official project. (I tried to explain this in the v1 announcement so I apologize if anyone, particularly Rusty, felt slightedit was not my intention) Can you describe what you are trying to achieve that virtio doesn't do? To be perfectly honest, I have never been able to find an implementation of virtio (I looked and even asked Rusty directly via email but never found/heard anything back) so I don't know exactly what its capabilities are. My impressions from reading Rusty's email proposals are that there are certainly similarities to the virtio interface and the ioq interface in concept. Where they seem to differ is that the concept of the ring is more exposed in IOQ via the iterator idiom instead of the sg-buffer idiom. At the time I first saw the virtio proposals, I couldn't quite wrap my head around how I could do things like zero copy + deferred pointer reaping, which was a design goal of mine. So I kept up with the IOQ design for the interim to at least demonstrate where I was trying to go. Perhaps it will be a useful innovation and the virtio interface design will pick up some of my ideas. Perhaps virtio deals with it already. Or perhaps no one will think its a good idea and it gets pushed to /dev/null ;) I am not sure what the answer will be. But in any case, I was also trying to go beyond the shared-ring interface design. For instance, the series also provides: *) a system for efficiently discovering/communicating with PV backend devices that was not laden with legacy interfaces like PCI. (I am in the process of converting over to use bus_register as Dor suggested). *) generalization of as much of the shared-memory code as possible so it could be reused (for instance, both guest and host can use the same IOQ interface, and the code itself will largely work with any hypervisor, or even non-hypervisor shared-memory systems, like RDMA/AMP). Again, perhaps virtio will cover all these areas too. Without having seen it I am not really sure where the overlap exists, but perhaps there will be at least some aspects of my series that are useful. That is why I submitted it. Ideally I can hook up with whomever is working on the implementation (sounds like Dor?) and we can crank something out together. :) Again, apologies if anyone felt slighted. :( -Greg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
Gregory Haskins wrote: If so, be aware that virtio is (a) mostly done (b) very well done. I would very much like to help make virtio work, which is really where I was going with this. My design is a little bit different so I was submitting it in case there was any ideas worth salvaging to be picked up by the official project. (I tried to explain this in the v1 announcement so I apologize if anyone, particularly Rusty, felt slightedit was not my intention) Alternative implementation ideas should of course not slight anyone but instead be welcomed. Can you describe what you are trying to achieve that virtio doesn't do? To be perfectly honest, I have never been able to find an implementation of virtio (I looked and even asked Rusty directly via email but never found/heard anything back) so I don't know exactly what its capabilities are. My impressions from reading Rusty's email proposals are that there are certainly similarities to the virtio interface and the ioq interface in concept. Where they seem to differ is that the concept of the ring is more exposed in IOQ via the iterator idiom instead of the sg-buffer idiom. Yes. virtio adapts the driver interface to an API can drive a shared memory queue more easily, while you actually provide the queue protocol (and ABI). At the time I first saw the virtio proposals, I couldn't quite wrap my head around how I could do things like zero copy + deferred pointer reaping, which was a design goal of mine. So I kept up with the IOQ design for the interim to at least demonstrate where I was trying to go. Perhaps it will be a useful innovation and the virtio interface design will pick up some of my ideas. Perhaps virtio deals with it already. Or perhaps no one will think its a good idea and it gets pushed to /dev/null ;) I am not sure what the answer will be. But in any case, I was also trying to go beyond the shared-ring interface design. For instance, the series also provides: *) a system for efficiently discovering/communicating with PV backend devices that was not laden with legacy interfaces like PCI. (I am in the process of converting over to use bus_register as Dor suggested). *) generalization of as much of the shared-memory code as possible so it could be reused (for instance, both guest and host can use the same IOQ interface, and the code itself will largely work with any hypervisor, or even non-hypervisor shared-memory systems, like RDMA/AMP). Again, perhaps virtio will cover all these areas too. Without having seen it I am not really sure where the overlap exists, but perhaps there will be at least some aspects of my series that are useful. That is why I submitted it. Ideally I can hook up with whomever is working on the implementation (sounds like Dor?) and we can crank something out together. :) virtio seems to have more modest goals: - make it easier to write guest/host (or guest/guest) transports, but not actually provide them - limited to guest only (and Linux only) - no discovery/hotplug (yet?) since it wants to be hypervisor agnostic, it cannot specify an ABI (as some already have ABIs, for example Xen). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH 0/9] PV device infrastructure v2
On Wed, 2007-08-15 at 05:50 +0300, Avi Kivity wrote: Gregory Haskins wrote: This series incorporates all of v1 plus the following changes based on feedback to date: Are you positioning this as an alternative to virtio? If so, be aware that virtio is (a) mostly done (b) very well done. Can you describe what you are trying to achieve that virtio doesn't do? As far as I can tell, Gregory in angling to take over the virtio work 8) Given how little cycles I've been able to spare recently, I think it's a good idea. I'm not particularly attached to the current virtio implementation, although I think the interface is getting pretty close. I'd love to see Gregory take over the implementation part... Rusty. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
