On Thu, Jun 16, 2011 at 11:01:22PM +0800, Asias He wrote:
On 06/16/2011 10:28 PM, Michael S. Tsirkin wrote:
On Wed, Jun 15, 2011 at 06:53:34PM +0300, Pekka Enberg wrote:
Hi all,
We’re proud to announce the second version of the Native Linux KVM tool!
We’re
now officially aiming for
On 06/16/2011 07:22 AM, Ingo Molnar wrote:
* Christoph Hellwigh...@infradead.org wrote:
On Thu, Jun 16, 2011 at 12:57:36PM +0300, Pekka Enberg wrote:
Uh-oh. Someone needs to apply this patch to sync_file_range():
There actually are a few cases where using it makes sense. [...]
Such as?
On 2011年06月15日 23:53, Pekka Enberg wrote:
or alternatively, if you already have a kernel source tree:
git remote add kvm-tool git://github.com/penberg/linux-kvm.git
git remote update
git checkout -b kvm-tool/master kvm-tool
I tried this, but it do not work, there is something wrong
On Fri, 2011-06-17 at 06:00 +0100, Stefan Hajnoczi wrote:
On Fri, Jun 17, 2011 at 2:03 AM, Sasha Levin levinsasha...@gmail.com wrote:
On Thu, 2011-06-16 at 17:50 -0500, Anthony Liguori wrote:
On 06/16/2011 09:48 AM, Pekka Enberg wrote:
On Wed, Jun 15, 2011 at 6:53 PM, Pekka
On 06/16/2011 08:03 PM, Sasha Levin wrote:
On Thu, 2011-06-16 at 17:50 -0500, Anthony Liguori wrote:
Each virtio-blk device can process requests regardless of other
virtio-blk devices, which means that we can do parallel requests for
devices.
Within each device, we support parallel requests in
On Thu, Jun 16, 2011 at 1:44 AM, Anthony Liguori anth...@codemonkey.ws wrote:
That's probably why it's fast, it doesn't preserve data integrity :(
Actually, I misread the code. It does unstable writes but it does do
fsync() on FLUSH.
On Thu, Jun 16, 2011 at 8:41 AM, Pekka Enberg
* Pekka Enberg penb...@kernel.org wrote:
On Thu, Jun 16, 2011 at 1:07 AM, Alexander Graf ag...@suse.de wrote:
qemu-system-x86_64 -drive
file=/dev/shm/test.qcow2,cache=writeback,if=virtio
Wouldn't this still be using threaded AIO mode? I thought KVM tools used
native AIO?
We don't
Hi Ingo,
On Thu, Jun 16, 2011 at 10:24 AM, Ingo Molnar mi...@elte.hu wrote:
- executing AIO in the vcpu thread eats up precious vcpu execution
time: combined QCOW2 throughput would be limited by a single
core's performance, and any time spent on QCOW2 processing would
not be spent
* Pekka Enberg penb...@kernel.org wrote:
Hi Ingo,
On Thu, Jun 16, 2011 at 10:24 AM, Ingo Molnar mi...@elte.hu wrote:
- executing AIO in the vcpu thread eats up precious vcpu execution
time: combined QCOW2 throughput would be limited by a single
core's performance, and any time
On Thu, Jun 16, 2011 at 8:24 AM, Ingo Molnar mi...@elte.hu wrote:
- executing AIO in the vcpu thread eats up precious vcpu execution
time: combined QCOW2 throughput would be limited by a single
core's performance, and any time spent on QCOW2 processing would
not be spent running the
On Thu, Jun 16, 2011 at 09:21:03AM +0300, Pekka Enberg wrote:
And btw, we use sync_file_range()
Which doesn't help you at all. sync_file_range is just a hint for VM
writeback, but never commits filesystem metadata nor the physical
disk's write cache. In short it's a completely dangerous
Hi Christoph,
On Thu, Jun 16, 2011 at 09:21:03AM +0300, Pekka Enberg wrote:
And btw, we use sync_file_range()
On Thu, Jun 16, 2011 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote:
Which doesn't help you at all. sync_file_range is just a hint for VM
writeback, but never commits
On Thu, Jun 16, 2011 at 12:34:04PM +0300, Pekka Enberg wrote:
Hi Christoph,
On Thu, Jun 16, 2011 at 09:21:03AM +0300, Pekka Enberg wrote:
And btw, we use sync_file_range()
On Thu, Jun 16, 2011 at 12:24 PM, Christoph Hellwig h...@infradead.org
wrote:
Which doesn't help you at all.
* Christoph Hellwig h...@infradead.org wrote:
What's the right thing to do here? Is fdatasync() sufficient?
Yes.
Prasad, Pekka, mind redoing the numbers with fdatasync()?
I'd be surprised if they were significantly worse but it has to be
done to have apples-to-apples numbers.
Thanks,
On Thu, Jun 16, 2011 at 12:48 PM, Christoph Hellwig h...@infradead.org wrote:
You also missed:
This system call does not flush disk write caches and thus does not
provide any data integrity on systems with volatile disk write
caches.
so it's not safe if you either have a cache, or are
On Thu, Jun 16, 2011 at 12:57:36PM +0300, Pekka Enberg wrote:
Uh-oh. Someone needs to apply this patch to sync_file_range():
There actually are a few cases where using it makes sense. It's just
the minority.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
* Christoph Hellwig h...@infradead.org wrote:
On Thu, Jun 16, 2011 at 12:57:36PM +0300, Pekka Enberg wrote:
Uh-oh. Someone needs to apply this patch to sync_file_range():
There actually are a few cases where using it makes sense. [...]
Such as? I don't think apps can actually know whether
On Thu, Jun 16, 2011 at 01:22:30PM +0200, Ingo Molnar wrote:
Such as? I don't think apps can actually know whether disk blocks
have been 'instantiated' by a particular filesystem or not, so the
manpage:
In general they can't. The only good use case for sync_file_range
is to paper
* Christoph Hellwig h...@infradead.org wrote:
On Thu, Jun 16, 2011 at 01:22:30PM +0200, Ingo Molnar wrote:
Such as? I don't think apps can actually know whether disk blocks
have been 'instantiated' by a particular filesystem or not, so
the manpage:
In general they can't. The only
On Thu, Jun 16, 2011 at 01:40:45PM +0200, Ingo Molnar wrote:
Filesystems that cannot guarantee that should map their
sync_file_range() implementation to fdatasync() or so, right?
Filesystems aren't even told about sync_file_range, it's purely a VM
thing, which is the root of the problem.
On Wed, Jun 15, 2011 at 06:53:34PM +0300, Pekka Enberg wrote:
Hi all,
We’re proud to announce the second version of the Native Linux KVM tool! We’re
now officially aiming for merging to mainline in 3.1.
Highlights:
- Experimental GUI support using SDL and VNC
- SMP support.
On Wed, Jun 15, 2011 at 6:53 PM, Pekka Enberg penb...@kernel.org wrote:
- Fast QCOW2 image read-write support beating Qemu in fio benchmarks. See the
following URL for test result details: https://gist.github.com/1026888
It turns out we were benchmarking the wrong guest kernel version for
On 06/16/2011 10:28 PM, Michael S. Tsirkin wrote:
On Wed, Jun 15, 2011 at 06:53:34PM +0300, Pekka Enberg wrote:
Hi all,
We’re proud to announce the second version of the Native Linux KVM tool!
We’re
now officially aiming for merging to mainline in 3.1.
Highlights:
- Experimental GUI
On 06/16/2011 09:48 AM, Pekka Enberg wrote:
On Wed, Jun 15, 2011 at 6:53 PM, Pekka Enbergpenb...@kernel.org wrote:
- Fast QCOW2 image read-write support beating Qemu in fio benchmarks. See the
following URL for test result details: https://gist.github.com/1026888
It turns out we were
On Thu, 2011-06-16 at 17:50 -0500, Anthony Liguori wrote:
On 06/16/2011 09:48 AM, Pekka Enberg wrote:
On Wed, Jun 15, 2011 at 6:53 PM, Pekka Enbergpenb...@kernel.org wrote:
- Fast QCOW2 image read-write support beating Qemu in fio benchmarks. See
the
following URL for test result
On Fri, Jun 17, 2011 at 2:03 AM, Sasha Levin levinsasha...@gmail.com wrote:
On Thu, 2011-06-16 at 17:50 -0500, Anthony Liguori wrote:
On 06/16/2011 09:48 AM, Pekka Enberg wrote:
On Wed, Jun 15, 2011 at 6:53 PM, Pekka Enbergpenb...@kernel.org wrote:
- Fast QCOW2 image read-write support
On Thu, Jun 16, 2011 at 3:48 PM, Pekka Enberg penb...@kernel.org wrote:
On Wed, Jun 15, 2011 at 6:53 PM, Pekka Enberg penb...@kernel.org wrote:
- Fast QCOW2 image read-write support beating Qemu in fio benchmarks. See the
following URL for test result details: https://gist.github.com/1026888
Hi all,
We’re proud to announce the second version of the Native Linux KVM tool! We’re
now officially aiming for merging to mainline in 3.1.
Highlights:
- Experimental GUI support using SDL and VNC
- SMP support. tools/kvm/ now has a highly scalable, largely lockless driver
interface and the
On 06/15/2011 06:53 PM, Pekka Enberg wrote:
- Fast QCOW2 image read-write support beating Qemu in fio benchmarks. See the
following URL for test result details: https://gist.github.com/1026888
This is surprising. How is qemu invoked?
btw the dump above is a little hard to interpret.
--
On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivity a...@redhat.com wrote:
On 06/15/2011 06:53 PM, Pekka Enberg wrote:
- Fast QCOW2 image read-write support beating Qemu in fio benchmarks. See
the
following URL for test result details: https://gist.github.com/1026888
This is surprising. How is
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enberg penb...@kernel.org wrote:
On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivity a...@redhat.com wrote:
On 06/15/2011 06:53 PM, Pekka Enberg wrote:
- Fast QCOW2 image read-write support beating Qemu in fio benchmarks. See
the
following URL for test result
On Wed, 2011-06-15 at 21:13 +0100, Prasad Joshi wrote:
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enberg penb...@kernel.org wrote:
On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivity a...@redhat.com wrote:
On 06/15/2011 06:53 PM, Pekka Enberg wrote:
- Fast QCOW2 image read-write support beating Qemu
On Wed, Jun 15, 2011 at 9:23 PM, Sasha Levin levinsasha...@gmail.com wrote:
On Wed, 2011-06-15 at 21:13 +0100, Prasad Joshi wrote:
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enberg penb...@kernel.org wrote:
On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivity a...@redhat.com wrote:
On 06/15/2011 06:53
On 06/15/2011 10:53 AM, Pekka Enberg wrote:
Hi all,
We’re proud to announce the second version of the Native Linux KVM tool! We’re
now officially aiming for merging to mainline in 3.1.
Highlights:
- Experimental GUI support using SDL and VNC
- SMP support. tools/kvm/ now has a highly
On 06/15/2011 03:13 PM, Prasad Joshi wrote:
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enbergpenb...@kernel.org wrote:
On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivitya...@redhat.com wrote:
On 06/15/2011 06:53 PM, Pekka Enberg wrote:
- Fast QCOW2 image read-write support beating Qemu in fio
On 16.06.2011, at 00:04, Anthony Liguori wrote:
On 06/15/2011 03:13 PM, Prasad Joshi wrote:
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enbergpenb...@kernel.org wrote:
On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivitya...@redhat.com wrote:
On 06/15/2011 06:53 PM, Pekka Enberg wrote:
- Fast QCOW2
On 06/15/2011 05:07 PM, Alexander Graf wrote:
On 16.06.2011, at 00:04, Anthony Liguori wrote:
On 06/15/2011 03:13 PM, Prasad Joshi wrote:
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enbergpenb...@kernel.org wrote:
On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivitya...@redhat.com wrote:
On
On 06/15/2011 05:20 PM, Anthony Liguori wrote:
On 06/15/2011 05:07 PM, Alexander Graf wrote:
On 16.06.2011, at 00:04, Anthony Liguori wrote:
On 06/15/2011 03:13 PM, Prasad Joshi wrote:
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enbergpenb...@kernel.org
wrote:
On Wed, Jun 15, 2011 at 7:30 PM,
On Wed, Jun 15, 2011 at 11:04 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 06/15/2011 03:13 PM, Prasad Joshi wrote:
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enbergpenb...@kernel.org wrote:
On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivitya...@redhat.com wrote:
On 06/15/2011 06:53 PM, Pekka
On Thu, Jun 16, 2011 at 1:44 AM, Anthony Liguori anth...@codemonkey.ws wrote:
That's probably why it's fast, it doesn't preserve data integrity :(
Actually, I misread the code. It does unstable writes but it does do
fsync() on FLUSH.
Yes. That's fine, right? Or did we misread how virtio
On Thu, Jun 16, 2011 at 8:29 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Wed, Jun 15, 2011 at 11:04 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
On 06/15/2011 03:13 PM, Prasad Joshi wrote:
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enbergpenb...@kernel.org wrote:
On Wed, Jun 15, 2011
On Thu, Jun 16, 2011 at 1:07 AM, Alexander Graf ag...@suse.de wrote:
qemu-system-x86_64 -drive file=/dev/shm/test.qcow2,cache=writeback,if=virtio
Wouldn't this still be using threaded AIO mode? I thought KVM tools used
native AIO?
We don't use AIO at all. It's just normal read()/write() with
On Sat, Apr 09, 2011 at 09:40:09AM +0200, Ingo Molnar wrote:
* Andrea Arcangeli aarca...@redhat.com wrote:
[...] I thought the whole point of a native kvm tool was to go all the
paravirt way to provide max performance and maybe also depend on vhost as
much as possible.
BTW, I should
On 04/09/2011 01:59 AM, Anthony Liguori wrote:
Yeah, if that's the goal, skip all the mini-BIOS junk and just rely on
a PV kernel in the guest.
I think a mini userspace that assumes that we can change the guest
kernel and avoids having a ton of complexity to do things like CMOS
emulation
* Andrea Arcangeli aarca...@redhat.com wrote:
[...] I thought the whole point of a native kvm tool was to go all the
paravirt way to provide max performance and maybe also depend on vhost as
much as possible.
To me it's more than that: today i can use it to minimally boot test various
On Fri, Apr 08, 2011 at 09:00:43AM -0500, Anthony Liguori wrote:
Really, having a flat table doesn't make sense. You should just send
everything to an i440fx directly. Then the i440fx should decode what it
can, and send it to the next level, and so forth.
No you shouldn't. The i440fx
On 04/09/2011 01:23 PM, Olivier Galibert wrote:
On Fri, Apr 08, 2011 at 09:00:43AM -0500, Anthony Liguori wrote:
Really, having a flat table doesn't make sense. You should just send
everything to an i440fx directly. Then the i440fx should decode what it
can, and send it to the next level, and
On Fri, Apr 8, 2011 at 9:14 AM, Pekka Enberg penb...@kernel.org wrote:
Hi Anthony,
On Fri, Apr 8, 2011 at 5:14 AM, Anthony Liguori anth...@codemonkey.ws wrote:
If someone was going to seriously go about doing something like this, a
better approach would be to start with QEMU and remove
Hi!
Hi Anthony,
On Fri, Apr 8, 2011 at 5:14 AM, Anthony Liguori anth...@codemonkey.ws wrote:
If someone was going to seriously go about doing something like this, a
better approach would be to start with QEMU and remove anything non-x86 and
all of the UI/command line/management bits and
Hi Takuya!
On Fri, Apr 8, 2011 at 9:47 AM, Takuya Yoshikawa
yoshikawa.tak...@oss.ntt.co.jp wrote:
Is it possible to find the code maintenance policy on a project site
or somewhere? -- for both short run and long run.
I may get some interest in using this tool for my debugging/testing/
I may get some interest in using this tool for my debugging/testing/
self-educational porpuses, but cannot know what I can do/expect.
Heh, it's all pretty straight-forward. Fetch the sources from this tree:
git clone git://github.com/penberg/linux-kvm.git
Find something interesting
On 2011-04-08 07:14, Pekka Enberg wrote:
Hi Anthony,
On Fri, Apr 8, 2011 at 5:14 AM, Anthony Liguori anth...@codemonkey.ws wrote:
If someone was going to seriously go about doing something like this, a
better approach would be to start with QEMU and remove anything non-x86 and
all of the
Hi Jan,
On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote:
I agree that it's easy to change 2kSomething LOC for this. But if you
now wait too long designing in essential features like SMP, a scalable
execution model, and - very important - portability (*), it can get
fairly painful to fix
On 2011-04-08 10:27, Pekka Enberg wrote:
Hi Jan,
On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote:
I agree that it's easy to change 2kSomething LOC for this. But if you
now wait too long designing in essential features like SMP, a scalable
execution model, and - very important -
On Fri, Apr 8, 2011 at 1:11 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-04-08 10:27, Pekka Enberg wrote:
Hi Jan,
On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote:
I agree that it's easy to change 2kSomething LOC for this. But if you
now wait too long designing in essential
On 2011-04-08 11:32, Cyrill Gorcunov wrote:
It seems there is a misunderstanding. KVM-tool is quite far from been KVM
replacement (if ever). And what we're doing -- extremely tiny/small HV which
would help us to debug/test kernel code.
I think your core team may have this vision, but my
On 08.04.2011, at 12:42, Jan Kiszka wrote:
On 2011-04-08 11:32, Cyrill Gorcunov wrote:
It seems there is a misunderstanding. KVM-tool is quite far from been KVM
replacement (if ever). And what we're doing -- extremely tiny/small HV which
would help us to debug/test kernel code.
I think
On Friday, April 8, 2011, Alexander Graf ag...@suse.de wrote:
On 08.04.2011, at 12:42, Jan Kiszka wrote:
On 2011-04-08 11:32, Cyrill Gorcunov wrote:
It seems there is a misunderstanding. KVM-tool is quite far from been KVM
replacement (if ever). And what we're doing -- extremely tiny/small
On 04/08/2011 12:14 AM, Pekka Enberg wrote:
Hey, feel free to help out! ;-)
I don't agree that a working 2500 LOC program is 'repeating the same
architectural mistakes' as QEMU. I hope you realize that we've gotten
here with just three part-time hackers working from their proverbial
basements.
On Fri, Apr 08, 2011 at 01:32:24PM +0400, Cyrill Gorcunov wrote:
It seems there is a misunderstanding. KVM-tool is quite far from been KVM
replacement (if ever). And what we're doing -- extremely tiny/small HV which
would help us to debug/test kernel code.
If that's true, then perhaps the
On Thu, 7 Apr 2011 21:14:06 -0500
Anthony Liguori anth...@codemonkey.ws wrote:
If someone was going to seriously go about doing something like this, a
better approach would be to start with QEMU and remove anything non-x86
and all of the UI/command line/management bits and start there.
Hi Anthony,
On Fri, Apr 08, 2011 at 09:00:43AM -0500, Anthony Liguori wrote:
An example is ioport_ops. This maps directly to
ioport_{read,write}_table in QEMU. Then you use ioport__register() to
register entries in this table similar register_ioport_{read,write}() in
QEMU.
The use of
On 04/08/2011 10:59 AM, Scott Wood wrote:
On Thu, 7 Apr 2011 21:14:06 -0500
Anthony Liguorianth...@codemonkey.ws wrote:
If someone was going to seriously go about doing something like this, a
better approach would be to start with QEMU and remove anything non-x86
and all of the UI/command
On 04/08/2011 02:20 PM, Andrea Arcangeli wrote:
Hi Anthony,
On Fri, Apr 08, 2011 at 09:00:43AM -0500, Anthony Liguori wrote:
An example is ioport_ops. This maps directly to
ioport_{read,write}_table in QEMU. Then you use ioport__register() to
register entries in this table similar
On 04/06/2011 05:55 AM, Ingo Molnar wrote:
Splitting up a project into several trees, often unnecessarily, is a
self-inflicted wound really.
There's certainly something to this but the bit that surprises me is the
approaching being taken.
Why not take perf and all the other tools, stick
On 04/06/2011 04:33 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
Sure, any succcesful project becomes an ugly gooball. It's almost a
compliment.
I disagree strongly with that sentiment and there's several good counter
examples:
- the Git project is also highly successful and
Hi Anthony,
On Fri, Apr 8, 2011 at 5:14 AM, Anthony Liguori anth...@codemonkey.ws wrote:
If someone was going to seriously go about doing something like this, a
better approach would be to start with QEMU and remove anything non-x86 and
all of the UI/command line/management bits and start
Anthony Liguori anth...@codemonkey.ws writes:
On 04/03/2011 05:11 AM, Avi Kivity wrote:
On 04/03/2011 12:59 PM, Pekka Enberg wrote:
Hi Avi,
On Sun, Apr 3, 2011 at 11:23 AM, Avi Kivitya...@redhat.com wrote:
Note that this is a development prototype for the time being:
there's no
On Wed, Apr 06, 2011 at 10:59:45AM +0200, Markus Armbruster wrote:
Anthony Liguori anth...@codemonkey.ws writes:
On 04/03/2011 05:11 AM, Avi Kivity wrote:
On 04/03/2011 12:59 PM, Pekka Enberg wrote:
Hi Avi,
On Sun, Apr 3, 2011 at 11:23 AM, Avi Kivitya...@redhat.com wrote:
Note
* Avi Kivity a...@redhat.com wrote:
Sure, any succcesful project becomes an ugly gooball. It's almost a
compliment.
I disagree strongly with that sentiment and there's several good counter
examples:
- the Git project is also highly successful and is kept very clean (and has a
project
On Wed, Apr 06, 2011 at 11:33:33AM +0200, Ingo Molnar wrote:
So no, your kind of cynical, defeatist sentiment about code quality is by no
means true in my experience. Projects become ugly gooballs once maintainers
stop caring enough.
In case of Qemu it was other way around. Maintainers
* Gleb Natapov g...@redhat.com wrote:
On Wed, Apr 06, 2011 at 11:33:33AM +0200, Ingo Molnar wrote:
So no, your kind of cynical, defeatist sentiment about code quality is by
no means true in my experience. Projects become ugly gooballs once
maintainers stop caring enough.
In case of
On 04/06/2011 12:46 PM, Ingo Molnar wrote:
* Gleb Natapovg...@redhat.com wrote:
On Wed, Apr 06, 2011 at 11:33:33AM +0200, Ingo Molnar wrote:
So no, your kind of cynical, defeatist sentiment about code quality is by
no means true in my experience. Projects become ugly gooballs once
On Wed, Apr 06, 2011 at 11:46:12AM +0200, Ingo Molnar wrote:
* Gleb Natapov g...@redhat.com wrote:
On Wed, Apr 06, 2011 at 11:33:33AM +0200, Ingo Molnar wrote:
So no, your kind of cynical, defeatist sentiment about code quality is by
no means true in my experience. Projects become
On Wed, Apr 06, 2011 at 11:33:33AM +0200, Ingo Molnar wrote:
Examples: X11 and GCC - both were struggling for years to break through magic
invisible barriers of growth and IMHO a lot of it had to do with the lack of
code (and development model) cleanliness.
A large part of what's killing X11
* Olivier Galibert galib...@pobox.com wrote:
On Wed, Apr 06, 2011 at 11:33:33AM +0200, Ingo Molnar wrote:
Examples: X11 and GCC - both were struggling for years to break through
magic
invisible barriers of growth and IMHO a lot of it had to do with the lack
of
code (and
* Pekka Enberg penb...@kernel.org wrote:
Well, this is bound to cause confusion as the tool is yet quite immature.
Yes, that's really unfortunate. I don't care too much what we call the tool
but I definitely agree with Ingo that 'kvm' is more discoverable to users.
Any suggestions?
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/31/2011 12:30 PM, Pekka Enberg wrote:
Hi all,
We’re proud to announce the native Linux KVM tool!
Neat!
As something of a lesson of history, I'd suggest picking a more unique name
while it's still a prototype :-)
I disagree, i
On 03/31/2011 07:30 PM, Pekka Enberg wrote:
Hi all,
We’re proud to announce the native Linux KVM tool!
So that's where you disappeared - I was following your old repository.
The goal of this tool is to provide a clean, from-scratch, lightweight
KVM host tool implementation that can boot
On 04/03/2011 09:21 AM, Ingo Molnar wrote:
* Anthony Liguorianth...@codemonkey.ws wrote:
On 03/31/2011 12:30 PM, Pekka Enberg wrote:
Hi all,
We’re proud to announce the native Linux KVM tool!
Neat!
As something of a lesson of history, I'd suggest picking a more unique name
Hi Anthony,
On Sat, Apr 2, 2011 at 11:38 PM, Anthony Liguori anth...@codemonkey.ws wrote:
The goal of this tool is to provide a clean, from-scratch, lightweight
KVM host tool implementation that can boot Linux guest images (just a
hobby, won't be big and professional like QEMU) with no BIOS
Hi,
On Sun, Apr 3, 2011 at 11:24 AM, Avi Kivity a...@redhat.com wrote:
On 04/03/2011 09:21 AM, Ingo Molnar wrote:
* Anthony Liguorianth...@codemonkey.ws wrote:
On 03/31/2011 12:30 PM, Pekka Enberg wrote:
Hi all,
We’re proud to announce the native Linux KVM tool!
Neat!
On Thu, Mar 31, 2011 at 08:30:56PM +0300, Pekka Enberg wrote:
Hi all,
We’re proud to announce the native Linux KVM tool!
The goal of this tool is to provide a clean, from-scratch, lightweight
KVM host tool implementation that can boot Linux guest images (just a
hobby, won't be big and
On 04/03/2011 12:53 PM, Pekka Enberg wrote:
Hi,
On Sun, Apr 3, 2011 at 11:24 AM, Avi Kivity a...@redhat.com wrote:
On 04/03/2011 09:21 AM, Ingo Molnar wrote:
* Anthony Liguorianth...@codemonkey.ws wrote:
On 03/31/2011 12:30 PM, Pekka Enberg wrote:
Hi all,
We’re proud to
On 04/03/2011 11:51 AM, Pekka Enberg wrote:
Hi Anthony,
On Sat, Apr 2, 2011 at 11:38 PM, Anthony Liguorianth...@codemonkey.ws wrote:
The goal of this tool is to provide a clean, from-scratch, lightweight
KVM host tool implementation that can boot Linux guest images (just a
hobby, won't
Hi Avi,
On Sun, Apr 3, 2011 at 11:23 AM, Avi Kivity a...@redhat.com wrote:
Note that this is a development prototype for the time being: there's no
networking support and no graphics support, amongst other missing
essentials.
Mind posting a roadmap? I would put smp support near the top.
On Sun, 2011-04-03 at 12:01 +0300, Alon Levy wrote:
On Thu, Mar 31, 2011 at 08:30:56PM +0300, Pekka Enberg wrote:
Hi all,
We’re proud to announce the native Linux KVM tool!
The goal of this tool is to provide a clean, from-scratch, lightweight
KVM host tool implementation that can
On 04/03/2011 12:59 PM, Pekka Enberg wrote:
Hi Avi,
On Sun, Apr 3, 2011 at 11:23 AM, Avi Kivitya...@redhat.com wrote:
Note that this is a development prototype for the time being: there's no
networking support and no graphics support, amongst other missing
essentials.
Mind posting a
On Sun, Apr 03, 2011 at 01:01:38PM +0300, Pekka Enberg wrote:
On Sun, 2011-04-03 at 12:01 +0300, Alon Levy wrote:
On Thu, Mar 31, 2011 at 08:30:56PM +0300, Pekka Enberg wrote:
Hi all,
We’re proud to announce the native Linux KVM tool!
The goal of this tool is to provide a
Hi Avi,
On Sun, Apr 3, 2011 at 1:11 PM, Avi Kivity a...@redhat.com wrote:
SMP, networking, and simpler guest to host communication from shell
are most interesting missing features for me.
If it is to be more than a toy, then Windows (really generic guest) support,
manageability, live
On 04/03/2011 01:17 PM, Pekka Enberg wrote:
Hi Avi,
On Sun, Apr 3, 2011 at 1:11 PM, Avi Kivitya...@redhat.com wrote:
SMP, networking, and simpler guest to host communication from shell
are most interesting missing features for me.
If it is to be more than a toy, then Windows (really
On Sun, Apr 03, 2011 at 11:53:34AM +0300, Pekka Enberg wrote:
Yes, that's really unfortunate. I don't care too much what we call the
tool but I definitely agree with Ingo that 'kvm' is more discoverable
Indeed. It's great for finding info on keyboard-video-mouse switches. :)
--
A search of
Hi Avi,
On Sun, Apr 3, 2011 at 1:22 PM, Avi Kivity a...@redhat.com wrote:
It's definitely not a toy, it's my main virtualization tool of choice
for kernel development! ;-)
The features you mention are crucial for servers but not for desktop.
I personally don't have much need for managing and
On 04/03/2011 05:11 AM, Avi Kivity wrote:
On 04/03/2011 12:59 PM, Pekka Enberg wrote:
Hi Avi,
On Sun, Apr 3, 2011 at 11:23 AM, Avi Kivitya...@redhat.com wrote:
Note that this is a development prototype for the time being:
there's no
networking support and no graphics support, amongst
On 04/03/2011 04:09 PM, Anthony Liguori wrote:
On 04/03/2011 05:11 AM, Avi Kivity wrote:
On 04/03/2011 12:59 PM, Pekka Enberg wrote:
Hi Avi,
On Sun, Apr 3, 2011 at 11:23 AM, Avi Kivitya...@redhat.com wrote:
Note that this is a development prototype for the time being:
there's no
On 03/31/2011 12:30 PM, Pekka Enberg wrote:
Hi all,
We’re proud to announce the native Linux KVM tool!
Neat!
As something of a lesson of history, I'd suggest picking a more unique
name while it's still a prototype :-)
The goal of this tool is to provide a clean, from-scratch, lightweight
On 31.03.2011 23:47, Alexander Graf wrote:
Did you take a look at kuli?
Right. If you want to take kuli as a start, and GPL is acceptable for
you ;-).
If kuli seems right, I suggest to go ahead and make an upstream git
repository for it. I'd be happy to keep contributing the s390 parts to
On Friday, April 1, 2011, Carsten Otte carst...@de.ibm.com wrote:
On 31.03.2011 23:47, Alexander Graf wrote:
Did you take a look at kuli?
Right. If you want to take kuli as a start, and GPL is acceptable for you ;-).
If kuli seems right, I suggest to go ahead and make an upstream git
On Thu, Mar 31, 2011 at 08:30:56PM +0300, Pekka Enberg wrote:
The goal of this tool is to provide a clean, from-scratch, lightweight
KVM host tool implementation that can boot Linux guest images (just a
hobby, won't be big and professional like QEMU)
That line looks very familiar...
I'm
Hi all,
We’re proud to announce the native Linux KVM tool!
The goal of this tool is to provide a clean, from-scratch, lightweight
KVM host tool implementation that can boot Linux guest images (just a
hobby, won't be big and professional like QEMU) with no BIOS
dependencies and with only the
100 matches
Mail list logo
