Date: Sun, 09 Jan 2011 16:42:28 -0800 From: Ted Mittelstaedt <tedm@mittelstaedt.us> To: freebsd-emulation@freebsd.org Subject: Re: Testing Luvalley with FreeBSD as dom0 Message-ID: <4D2A55F4.6010704@mittelstaedt.us> In-Reply-To: <AANLkTik9Ckh2UAaed=YYbBFCP6yyd6kOmSXdEYmZPiEd@mail.gmail.com> References: <20100418191752.GA72730@triton8.kn-bremen.de> <w2r3b0605b31004181554tb90de59u6df8ebd5b1206caa@mail.gmail.com> <AANLkTi=nhk%2BeCG6kbe4LfeaTQWkKaVcr%2BRx2LrKparDO@mail.gmail.com> <20110107194516.GA28544@triton8.kn-bremen.de> <AANLkTikvP8SezKEZYSUimaj3u8fkk2Vw6-aY09KV=RF3@mail.gmail.com> <20110107213643.GA32645@triton8.kn-bremen.de> <AANLkTi=2Nn8xeKudxb2uSR=aLx0GW43gVPCdL-=hjP7z@mail.gmail.com> <AANLkTikbuWJbtPYaLW=8BEH4f5oiumzEN6rgwOB5tC=R@mail.gmail.com> <20110109110022.GA10789@triton8.kn-bremen.de> <AANLkTik9Ckh2UAaed=YYbBFCP6yyd6kOmSXdEYmZPiEd@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think the Luvalley architecture is fascinating but one of the larger problems that has always been faced by the Open Source Community has been lack of device driver support for all of the many peripherals and motherboards and bits of hardware out there. This is the problem with "bare metal" hypervisors, we see exactly the same problem with commercial use of the ESXi "bare metal" hypervisor - limited device driver support - and the worst, being disk driver support. ESXi, being based on Linux, has no good support for SATA-raid (ie: poor mans pseudo RAID 0 ) FreeBSD by contrast, has excellent support, far better than Linux. The practical reality of it is I can go out and buy a brand new, super-fast computer and run FreeBSD 8 on it then VirtualBox on that, then my guest OS's under VirtualBox - and get the same performance as a bare-metal hypervisor like ESXi or Luvalley on older hardware. And, with the FreeBSD/VirtualBox way, I get access to a far wider array of hardware including disk RAID hardware. Thus, I have to say that I feel the bare-metal hypervisor approach is a dead-end. Yes, I realize ESX has made a lot of money with this approach but the newest hardware coming on the scene is incredibly fast. Even if you put pseudo raid support into luvalley, your never going to get the kind of hardware support that you can get from an operating system that is used for far many more things than just virtualization. Ted On 1/9/2011 5:57 AM, Xiaodong Yi wrote: > Yes, license is a big problem. And I'm sorry to let you and Brandon > know that Luvalley is currently using KVM's code. And I think it's > hard and unnecessary to write the virtualization code from scratch. Do > you think so? > > Best regards, > > Xiaodong > > 2011/1/9 Juergen Lock<nox@jelal.kn-bremen.de>: >> On Sun, Jan 09, 2011 at 12:33:59AM -0600, Brandon Gooch wrote: >>> On Sun, Jan 9, 2011 at 12:01 AM, Xiaodong Yi<xdong.yi@gmail.com> wrote: >>>> Hi, >>>> >>>> I confirm that I no longer have time for Luvalley. However, I will be >>>> extreemly happy if anybody is willing to take over from me. >>>> Especially, I quite agree to customize Luvalley for FreeBSD, through >>>> it supports all kinds of Dom0 OSes. Howerver, I hope that the LIGHT >>>> architecture of Luvalley could be kept. Maybe it is useful to patch >>>> dom0 FreeBSD kernel (especially for interrupt handling), but it should >>>> not be very complex. Part of the code comes from KVM, and I suggest to >>>> keep flying with KVM to make sure that guest VMs work well. >>> >>> I believe that if serious effort were to be put forward by the FreeBSD >>> developers to further develop the code, the result would need to be >>> GPL and Linux free (or VERY close to it). This is an area of >>> contention within the FreeBSD developer and user community, so it >>> would need to be addressed. As the developer of Luvalley, do you have >>> the ability to re-license the code using a BSD license? >>> >>> Are there too many technical issues with the code to do this? Juergen >>> mentioned that bits of the code are based on (or pulled directly >>> from?) Linux KVM. That probably wouldn't fly here... >>> >>>> Luvalley does boot and run on bare hardware. But it does not taint >>>> dom0 FreeBSD. Although the `non-root' mode dom0 FreeBSD kernel has >>>> direct access to BIOS and hardware, Luvalley tries hard to coordinate >>>> with it. For example, Luvalley traps the BIOS calls from the FreeBSD >>>> kernel to report the modified E820 table. Another example is that >>>> Luvalley uses NMI as the IPI interrupt to avoid conflict with BSD >>>> kernel. And I also believe that simple patches could work if some >>>> corners of FreeBSD kernel are tainted. >>>> >>>> Regards, and looking forward to the following news ... >>>> >>>> Xiaodong >>> >>> As am I... >>> >>> Thanks for chiming in Xiaodong! >> >> Actually with `tainting' the FreeBSD kernel I meant causing it to be >> affected by the gpl and its requirements. So if someone were to ship >> e.g. an appliance that uses Luvalley and a modified FreeBSD kernel he >> would only have to provide sourcecode of Luvalley and the userland >> Luvalley version of qemu-kvm, not of his FreeBSD kernel modifications, >> or of other (non-gpl) userland apps for that matter. >> >> But again, IANAL. :) >> >> Cheers, >> Juergen (also hoping Luvalley will have a future...) >> > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D2A55F4.6010704>