On 12/07/2011 09:16 AM, Ingo Molnar wrote:
That's what's happening here; we're __powerpc64__ and
!__KERNEL__, tools/kvm/include/linux/types.h includes
asm/types.h so gets the int-l64.h definition of __u64, as
above. :/
builtin-run.c:389: error: format `%llx' expects type `long
long
On Tue, Dec 6, 2011 at 10:45 AM, Sasha Levin levinsasha...@gmail.com wrote:
Rusty has just removed it out of the spec. Since we probably the only ones
who implemented support for it, we should remove it out of our code as well.
There is no issue with breaking anything since nothing else worked
On Tue, Dec 6, 2011 at 10:07 AM, Sasha Levin levinsasha...@gmail.com wrote:
The code doesn't build after this patch due to missing header issues
which you fixed in patches #10 #11. Could you please move those two to
the beginning of the series for the sake of bisectablilty?
I did that myself.
On Tue, Dec 6, 2011 at 5:40 AM, Matt Evans m...@ozlabs.org wrote:
term_getc()'s int c has one byte written into it (at its lowest address) by
read_in_full(). This is expected to be the least significant byte, but that
isn't the case on BE! Use correct type, unsigned char. A similar issue
On Tue, Dec 6, 2011 at 5:42 AM, Matt Evans m...@ozlabs.org wrote:
vesa, pci-shmem and virtio-pci devices need to set up config space with
little-endian conversions (as config space is LE). The pci_config_address
bitfield also needs to be reversed when building on BE systems.
Signed-off-by:
On Tue, Dec 6, 2011 at 5:42 AM, Matt Evans m...@ozlabs.org wrote:
The field size is currently wrong, read into a 32bit word instead of 16. This
casues trouble when BE.
Signed-off-by: Matt Evans m...@ozlabs.org
---
tools/kvm/virtio/pci.c | 3 +--
1 files changed, 1 insertions(+), 2
On Tue, Dec 6, 2011 at 5:40 AM, Matt Evans m...@ozlabs.org wrote:
cpios are valid as initrds too, so allow them through the check.
Signed-off-by: Matt Evans m...@ozlabs.org
---
tools/kvm/kvm.c | 8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/kvm.c
On Tue, Dec 6, 2011 at 5:41 AM, Matt Evans m...@ozlabs.org wrote:
This patch passes the initrd fd and commandline to load_flat_binary(), which
may
be used to load both the kernel an initrd (stashing or inserting the
commandline as appropriate) in the same way that load_bzimage() does. This
On Tue, Dec 6, 2011 at 1:28 PM, Asias He asias.he...@gmail.com wrote:
@@ -116,8 +116,7 @@ static bool virtio_pci__io_in(struct ioport *ioport,
struct kvm *kvm, u16 port,
break;
case VIRTIO_PCI_QUEUE_NUM:
val = vtrans-virtio_ops-get_size_vq(kvm, vpci-dev,
On Tue, Dec 6, 2011 at 12:28 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Tue, Dec 06, 2011 at 12:25:29PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:42 AM, Matt Evans m...@ozlabs.org wrote:
vesa, pci-shmem and virtio-pci devices need to set up config space with
little-endian
On Tue, 2011-12-06 at 15:47 +0400, Cyrill Gorcunov wrote:
On Tue, Dec 06, 2011 at 01:41:56PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 12:28 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Tue, Dec 06, 2011 at 12:25:29PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:42 AM
On Tue, 6 Dec 2011, Sasha Levin wrote:
This enables the custom rootfs to run executables which have dylibs located
in non standard paths by taking these settings from the host.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/builtin-setup.c |1 +
1 files changed, 1
On Tue, 6 Dec 2011, Cyrill Gorcunov wrote:
On Tue, Dec 06, 2011 at 01:58:24PM +0200, Pekka Enberg wrote:
On Tue, 2011-12-06 at 15:47 +0400, Cyrill Gorcunov wrote:
On Tue, Dec 06, 2011 at 01:41:56PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 12:28 PM, Cyrill Gorcunov gorcu...@gmail.com
On Tue, Dec 6, 2011 at 8:03 PM, Scott Wood scottw...@freescale.com wrote:
I'm seeing a lot of double-underscores -- is this common style in KVM
tool? It's reserved for use by the compiler and system library. It's
common in the kernel (though not used like this for namespace
prefixes), but
On Tue, Dec 6, 2011 at 10:07 AM, Sasha Levin levinsasha...@gmail.com wrote:
The code doesn't build after this patch due to missing header issues
which you fixed in patches #10 #11. Could you please move those two to
the beginning of the series for the sake of bisectablilty?
I did that myself.
On Tue, Dec 6, 2011 at 5:40 AM, Matt Evans m...@ozlabs.org wrote:
term_getc()'s int c has one byte written into it (at its lowest address) by
read_in_full(). This is expected to be the least significant byte, but that
isn't the case on BE! Use correct type, unsigned char. A similar issue
On Tue, Dec 6, 2011 at 5:40 AM, Matt Evans m...@ozlabs.org wrote:
cpios are valid as initrds too, so allow them through the check.
Signed-off-by: Matt Evans m...@ozlabs.org
---
tools/kvm/kvm.c | 8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/kvm.c
On Tue, Dec 6, 2011 at 5:41 AM, Matt Evans m...@ozlabs.org wrote:
This patch passes the initrd fd and commandline to load_flat_binary(), which
may
be used to load both the kernel an initrd (stashing or inserting the
commandline as appropriate) in the same way that load_bzimage() does. This
On Tue, Dec 6, 2011 at 1:28 PM, Asias He asias.he...@gmail.com wrote:
@@ -116,8 +116,7 @@ static bool virtio_pci__io_in(struct ioport *ioport,
struct kvm *kvm, u16 port,
break;
case VIRTIO_PCI_QUEUE_NUM:
val = vtrans-virtio_ops-get_size_vq(kvm, vpci-dev,
On Tue, Dec 6, 2011 at 12:28 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Tue, Dec 06, 2011 at 12:25:29PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:42 AM, Matt Evans m...@ozlabs.org wrote:
vesa, pci-shmem and virtio-pci devices need to set up config space with
little-endian
On Tue, 2011-12-06 at 15:47 +0400, Cyrill Gorcunov wrote:
On Tue, Dec 06, 2011 at 01:41:56PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 12:28 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Tue, Dec 06, 2011 at 12:25:29PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:42 AM
On Tue, Dec 6, 2011 at 8:03 PM, Scott Wood scottw...@freescale.com wrote:
I'm seeing a lot of double-underscores -- is this common style in KVM
tool? It's reserved for use by the compiler and system library. It's
common in the kernel (though not used like this for namespace
prefixes), but
On Wed, 30 Nov 2011, Asias He wrote:
In virtio net's notify_vq(), we simply signal the tx/rx handle thread
and return.
Why not use the threadpool?
No.
Sasha?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo
On Thu, Dec 1, 2011 at 10:58 AM, Sasha Levin levinsasha...@gmail.com wrote:
I was looking into the concept of adding 'dedicated' threads to the
threadpool, since when the threadpool was added originally one of the
purposes was to have all worker threads in a single place.
This way we could
On Fri, Dec 2, 2011 at 9:16 AM, Sasha Levin levinsasha...@gmail.com wrote:
This patch adds a '--sandbox' argument when used in conjuction with a custom
rootfs, it allows running a script or an executable in the guest environment
by using executables and other files from the host.
This is
On Fri, 2011-12-02 at 09:26 +0200, Pekka Enberg wrote:
On Fri, Dec 2, 2011 at 9:16 AM, Sasha Levin levinsasha...@gmail.com wrote:
This patch adds a '--sandbox' argument when used in conjuction with a custom
rootfs, it allows running a script or an executable in the guest environment
by using
On Fri, Dec 2, 2011 at 9:44 AM, Sasha Levin levinsasha...@gmail.com wrote:
Would it not be better to introduce a new command that works like 'perf
stat', for example:
./kvm sandbox -k kernel to test -- trinity --mode=random --quiet -i
?
So basically proxy the first set of parameters to
On Tue, 29 Nov 2011, Sasha Levin wrote:
+/*
+ * Each buffer in the virtqueues is actually a chain of descriptors. This
+ * function returns the next descriptor in the chain, or vq-vring.num if we're
+ * at the end.
+ */
+static unsigned next_desc(struct vring_desc *desc,
+
On Tue, 29 Nov 2011, Sasha Levin wrote:
A guest could overwrite host memory by writing to cmos index bigger than 128.
This patch adds a boundry check to limit it to that size.
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Signed-off-by: Sasha Levin
On Mon, Nov 28, 2011 at 7:54 PM, Sasha Levin levinsasha...@gmail.com wrote:
Indirect buffers are ring descriptors which point to more (even more)
descriptors.
This can be used to increase the effective ring capacity, which helps the
guest to batch large requests - very useful for blk devices.
On Mon, Nov 28, 2011 at 7:34 AM, Asias He asias.he...@gmail.com wrote:
There are at most bdev-reqs[VIRTIO_BLK_QUEUE_SIZE] outstanding requests
at any time. We can simply use the head of each request to fetch the
right 'struct blk_dev_req' in bdev-reqs[].
So, we can eliminate the list and
On Fri, Nov 25, 2011 at 5:47 PM, Asias He asias.he...@gmail.com wrote:
This patch also fixes fio seq-read hang problem.
root@guest-kvm:~# cat seq-read.fio
[seq-read]
rw=read
bs=4096
size=512m
direct=1
filename=/dev/vdb
root@guest-kvm:~# fio seq-read.fio
random-read:
On Thu, 24 Nov 2011, Lan Tianyu wrote:
When meeting request to write the cluster without copied flag,
allocate a new cluster and write original data with modification
to the new cluster. This also adds support for the writing operation
of the qcow2 compressed image. After testing, image file can
On Mon, Nov 21, 2011 at 9:12 AM, Lan Tianyu tianyu@intel.com wrote:
+/*Allocate clusters according to the size. Find a postion that
+ *can satisfy the size. free_clust_idx is initialized to zero and
+ *Record last position.
+*/
Can you please fix up your comments to use the following
On Sun, 2011-11-20 at 14:14 +0800, Lan, Tianyu wrote:
OK. Thx.
But fsync is too slow. I try to find a way to sync a range of file.
Are there any solutions to meet my purpose?
On Sun, 2011-11-20 at 08:23 +0200, Sasha Levin wrote:
fdatasync() is as good as it'll get.
tbh, maybe we should
On Thu, Nov 17, 2011 at 3:04 PM, Sasha Levin levinsasha...@gmail.com wrote:
Support the event index feature in the virtio spec.
The results are less notifications between the guest and host, and in
result faster operation of the virt queues.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
On Thu, 2011-11-17 at 15:24 +0200, Pekka Enberg wrote:
On Thu, Nov 17, 2011 at 3:04 PM, Sasha Levin levinsasha...@gmail.com wrote:
Support the event index feature in the virtio spec.
The results are less notifications between the guest and host, and in
result faster operation of the virt
On Thu, Nov 17, 2011 at 8:07 AM, Sasha Levin levinsasha...@gmail.com wrote:
Also, when I start the guest I sometimes get the following error message:
# kvm run -k /path/to/bzImage-3.0.8 -m 256 -c 1 --name guest-15757
KVM_GET_SUPPORTED_CPUID failed: Argument list too long
Heh, we were
On Mon, Nov 14, 2011 at 4:04 AM, Asias He asias.he...@gmail.com wrote:
Why both the bandwidth and latency performance are dropping so dramatically
with multiple VQ?
What's the expected benefit from multiple VQs i.e. why are doing the
patches Sasha?
--
To unsubscribe from this list: send the
On Thu, Nov 10, 2011 at 9:57 AM, Markus Armbruster arm...@redhat.com wrote:
3) The block probing code replicates a well known CVE from three
years ago[1]. Using kvm-tool, a malicious guest could write the
qcow2 signature to the zero sector and use that to attack the host.
We don't support
On Thu, Nov 10, 2011 at 10:23 AM, Sasha Levin levinsasha...@gmail.com wrote:
I'm actually not sure why KVM tool got QCOW support in the first
place. You can have anything QCOW provides if you use btrfs (among
several other FSs).
To make it easy for people to use their existing images. I would
Hi Anthony,
On Thu, Nov 10, 2011 at 3:43 PM, Anthony Liguori anth...@codemonkey.ws wrote:
It's not just the qcow2 implementation or even the block layer. This pull
requests adds a userspace TCP/IP stack to the kernel and yet netdev isn't on
the CC and there are no Ack's from anyone from the
On Tue, 2011-11-01 at 18:34 +0200, Sasha Levin wrote:
This patch adds an option to provide information about redirection
of terminal redirection to a PTY device within 'kvm stat'.
Usage:
'kvm stat -p [term] -n [instance_name]'
Will print information about redirection of terminal
On Wed, 9 Nov 2011, Michael S. Tsirkin wrote:
KVM tool actually has support for 64bit features, we can probably remove
that when Pekka isn't looking :)
It's not yet released so maybe it's not an issue yet.
If it's too late I can re-add them to legacy too.
Pekka, 64 features aren't yet used
On Wed, 9 Nov 2011, Sasha Levin wrote:
They don't exist in kernel code either, for same reason as above.
Nothing will break if we remove it since no one really used it, we were
probably the first and only implementation of the spec which considered
them :)
As long as we are able to run older
On Wed, Nov 9, 2011 at 9:03 PM, Sasha Levin levinsasha...@gmail.com wrote:
+struct virtio_trans {
+ void *virtio;
+ enum VIRTIO_TRANS_TYPE type;
+ struct virtio_trans_ops trans_ops;
+ struct virtio_ops virtio_ops;
+};
Why are the ops not
On Wed, 2011-11-09 at 20:56 +0200, Richard Weinberger wrote:
On Wed, 9 Nov 2011 20:00:06 +0400, Cyrill Gorcunov gorcu...@gmail.com
wrote:
On Wed, Nov 09, 2011 at 05:49:53PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 17:42 +0200, Richard Weinberger wrote:
On Wed, 09 Nov 2011 16:49:51
Hi Anthony,
On 11/04/2011 03:38 AM, Pekka Enberg wrote:
Hi Linus,
Please consider pulling the latest KVM tool tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
kvmtool/for-linus
[snip]
tools/kvm/virtio/net.c | 423
tools/kvm/virtio/pci.c | 319
On Tue, 8 Nov 2011, Theodore Tso wrote:
It's great to hear that! But in that case, there's an experiment we
can't really run, which is if perf had been developed in a separate
tree, would it have been just as successful?
Experiment, eh?
We have the staging tree because it's a widely
On Tue, 8 Nov 2011, Theodore Tso wrote:
We have the staging tree because it's a widely acknowledged belief that
kernel code in the tree tends to improve over time compared to code
that's sitting out of the tree. Are you disputing that belief?
Kernel code in the kernel source tree improves;
On Tue, 8 Nov 2011, Frank Ch. Eigler wrote:
Almost: they demonstrate that those parts of the ABI that these
particular perf commands rely on have been impressively compatible.
Do you have any sort of ABI coverage measurement, to see what
parts of the ABI these perf commands do not use?
It's
On Tue, Nov 8, 2011 at 3:29 PM, Karel Zak k...@redhat.com wrote:
I don't know if it makes sense to merge the tools you've mentioned above.
My gut feeling is that it's probably not reasonable - there's already a
community working on it with their own development process and coding
style. I
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig h...@infradead.org wrote:
Nevermind that running virtfs as a rootfs is a really dumb idea. You
do now want to run a VM that has a rootfs that gets changed all the
time behind your back.
It's rootfs binaries that are shared, not configuration.
Hi Richard,
(I'm adding Sasha to the CC.)
On Tue, Nov 8, 2011 at 4:44 PM, richard -rw- weinberger
richard.weinber...@gmail.com wrote:
Pekka,
On Fri, Nov 4, 2011 at 9:38 AM, Pekka Enberg penb...@cs.helsinki.fi wrote:
./kvm run
We also support booting both raw images and QCOW2 images
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@redhat.com wrote:
No, having the source code in Linux kernel tree is perfectly useless for the
exceptional case, and forces you to go through extra hoops to build only one
component. Small hoops such as adding -- tools/kvm to git bisect
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@redhat.com wrote:
(BTW, I'm also convinced like Ted that not having a defined perf ABI might
have made sense in the beginning, but it has now devolved into bad software
engineering practice).
I'm not a perf maintainer so I don't know what
On 11/07/2011 09:09 AM, Pekka Enberg wrote:
We are obviously also using specifications but as you damn well should
know, specifications don't matter nearly as much as working code.
On Mon, 7 Nov 2011, Paolo Bonzini wrote:
Specifications matter much more than working code. Quirks are a fact
On 11/07/2011 09:45 AM, Pekka Enberg wrote:
Specifications matter much more than working code. Quirks are a fact
of life but should always come second.
To quote Linus:
And I have seen _lots_ of total crap work that was based on specs. It's
_the_ single worst way to write software
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann kra...@redhat.com wrote:
No support for booting from CDROM.
No support for booting from Network.
Thus no way to install a new guest image.
Sure. It's a pain point which we need to fix.
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann
On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
It's not just about code, it's as much about culture and development process.
Indeed. The BSDs have both kernel and the base system in a single
repository. There are probably good reasons for (and against) it.
In Linux we don't have that culture. No
On Mon, 7 Nov 2011, Kevin Wolf wrote:
Makes it a lot less hackable for me unless you want to restrict the set
of potential developers to Linux kernel developers...
We're not restricting potential developers to Linux kernel folks. We're
making it easy for them because we believe that the KVM
On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Indeed I do not see any advantage, since all the interfaces they use are
stable anyway (sysfs, msr.ko).
If they had gone in x86info, for example, my distro (F16, not exactly
conservative) would have likely picked those
On Mon, Nov 7, 2011 at 2:18 PM, Gerd Hoffmann kra...@redhat.com wrote:
tools/ lacks a separation into kernel hacker's testing+debugging
toolbox and userspace tools. It lacks proper buildsystem integration
for the userspace tools, there is no make tools and also no make
tools_install.
Hi Avi,
On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity a...@redhat.com wrote:
tools/power was merged in just 2 versions ago, do you think that
merging that was a mistake?
Things like tools/power may make sense, most of the code is tied to the
kernel interfaces. tools/kvm is 20k lines and is
Hi Ted,
On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o ty...@mit.edu wrote:
And the same problems will exist with kvm-tool. What if you need to
release a new version of kvm-tool? Does that mean that you have to
release a new set of kernel binaries? It's a mess, and there's a
reason why we don't
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@mit.edu wrote:
Perf was IMHO an overreaction caused by the fact that systemtap and
oprofile people packaged and released the sources in a way that kernel
developers didn't like.
I don't think perf should be used as a precendent that now argues
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@mit.edu wrote:
I don't think perf should be used as a precendent that now argues that
any new kernel utility should be moved into the kernel sources. Does
it make sense to move all of mount, fsck, login, etc., into the kernel
sources? There are
On Mon, 2011-11-07 at 17:19 +0200, Sasha Levin wrote:
Signed-off-by: Sasha Levin levinsasha...@gmail.com
-ENOCHANGELOG :-)
I assume this is related to the git problems Darren Hart reported on
Google Plus?
---
tools/kvm/virtio/9p.c | 25 +
1 files changed, 25
On Mon, 2011-11-07 at 17:38 +0200, Sasha Levin wrote:
On Mon, 2011-11-07 at 17:38 +0200, Pekka Enberg wrote:
On Mon, 2011-11-07 at 17:19 +0200, Sasha Levin wrote:
Signed-off-by: Sasha Levin levinsasha...@gmail.com
-ENOCHANGELOG :-)
I assume this is related to the git problems
Cc: Sasha Levin levinsasha...@gmail.com
Cc: Asias He asias.he...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Signed-off-by: Pekka Enberg penb...@kernel.org
---
tools/kvm/Makefile |3 +-
tools/kvm/builtin-run.c | 48 ++-
2 files changed, 49
On Mon, 7 Nov 2011, Pekka Enberg wrote:
I've never heard ABI incompatibility used as an argument for perf. Ingo?
On Mon, Nov 7, 2011 at 7:03 PM, Vince Weaver vi...@deater.net wrote:
Never overtly. They're too clever for that.
If you want me to take you seriously, spare me from the conspiracy
On Mon, 7 Nov 2011, Frank Ch. Eigler wrote:
The ABI design allows for that kind of flexible extensibility, and
it's one of its major advantages.
What we *cannot* protect against is you relying on obscure details of
the ABI [...]
Is there some documentation that clearly spells out which parts
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o ty...@mit.edu wrote:
Personally, I consider code that runs in userspace as a pretty bright
line, as being not kernel code, and while perhaps things like
initramfs and the crazy ideas people have had in the past of moving
stuff out of
On Mon, 7 Nov 2011, Darren Hart wrote:
Could you try cloning a small repository and see if it works for you?
sh-4.2# git clone git://github.com/dvhart/braindump.git
Cloning into braindump...
remote: Counting objects: 1014, done.
remote: Compressing objects: 100% (441/441), done.
Receiving
Hi Alexander,
On Sun, Nov 6, 2011 at 3:35 AM, Alexander Graf ag...@suse.de wrote:
On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
would be doing and what he expects from it. Basically he wants a
small and simple tool he and other developers can run to try out and
see if
On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity a...@redhat.com wrote:
I'm happy to see some real competition for the KVM tool in usability. ;-)
That said, while the script looks really useful for developers,
wouldn't it make more sense to put it in QEMU to make sure it's kept
up-to-date and
Hi Avi,
On Sun, 2011-11-06 at 12:23 +0200, Avi Kivity wrote:
If this is a serious attempt in making QEMU command line suck less on
Linux, I think it makes sense to do this properly instead of adding a
niche script to the kernel tree that's simply going to bit rot over
time.
You
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@redhat.com wrote:
People seem to think the KVM tool is only about solving a specific
problem to kernel developers. That's certainly never been my goal as I
do lots of userspace programming as well. The end game for me is to
replace
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@redhat.com wrote:
So far, kvm-tool capabilities are a subset of qemu's. Does it add
anything beyond a different command-line?
I think different command line is a big thing which is why we've
spent so much time on it. But if you mean other end
On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity a...@redhat.com wrote:
But from your description, you're trying to solve just another narrow
problem:
The end game for me is to replace QEMU/VirtualBox for Linux on Linux
virtualization for my day to day purposes.
We rarely merge a subsystem to
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
You say that kvm-tool's scope is broader than Alex's script, therefore
the latter is pointless.
I'm saying that Alex's script is pointless because it's not attempting
to fix the real issues. For example, we're trying to make make
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
Alex's script, though, is just a few dozen lines. kvm-tool is a 20K
patch - in fact 2X as large as kvm when it was first merged. And it's
main feature seems to be that it is not qemu.
I think I've mentioned many times that I
Hi Jan,
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@web.de wrote:
Usable - I've tried kvm-tool several times and still (today) fail to
get a standard SUSE image (with a kernel I have to compile and provide
separately...) up and running *). Likely a user mistake, but none that
is
Hi Avi,
On Sun, Nov 6, 2011 at 5:56 PM, Avi Kivity a...@redhat.com wrote:
On 11/06/2011 03:06 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
You say that kvm-tool's scope is broader than Alex's script, therefore
the latter is pointless.
I'm
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@web.de wrote:
In contrast, you can throw arbitrary Linux distros in various forms at
QEMU, and it will catch and run them. For me, already this is more usable.
Yes, I completely agree that this is an unfortunate limitation in the
KVM tool.
On Sun, 6 Nov 2011, Jan Kiszka wrote:
Can you please share your kernel .config with me and I'll take a look
at it. We now have a make kvmconfig makefile target for enabling all
the necessary config options for guest kernels. I don't think any of
us developers are using SUSE so it can surely be a
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf ag...@suse.de wrote:
The difference here is that although I feel Alex's script is a
pointless project, I'm in no way opposed to merging it in the tree if
people use it and it solves their problem. Some people seem to be
violently opposed to
On Sun, 6 Nov 2011, Jan Kiszka wrote:
Doesn't help here (with a disk image).
Also, both dependencies make no sense to me as we boot from disk, not
from net, and the console is on ttyS0.
It's only VIRTIO_NET and the guest is not actually stuck, it just takes a
while to boot:
[1.866614]
On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf ag...@suse.de wrote:
That's pretty much what git submodule would do, isn't it?
I really don't see the point in doing that. We want to be part of
regular kernel history and release cycle. We want people to be able to
see what's going on in our
On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori anth...@codemonkey.ws wrote:
I'm quite happy with KVM tool and hope they continue working on it. My only
real wish is that they wouldn't copy QEMU so much and would try bolder
things that are fundamentally different from QEMU.
Hey, right now our
On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
I'm quite happy with KVM tool and hope they continue working on it.
My only real wish is that they wouldn't copy QEMU so much and would
try bolder things that are fundamentally different from QEMU.
On Sun, Nov 6, 2011 at 8:31 PM,
On Sun, Nov 6, 2011 at 8:54 PM, Pekka Enberg penb...@kernel.org wrote:
So integrating kvm-tool into the kernel isn't going to work as a free
pass to make non-backwards compatible changes to the KVM user/kernel
interface. Given that, why bloat the kernel source tree size?
Ted, I'm confused
On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini pbonz...@redhat.com wrote:
I really don't see the point in doing that. We want to be part of
regular kernel history and release cycle.
But I'm pretty certain that, when testing 3.2 with KVM tool in a couple of
years, I want all the shining new
On Sun, Nov 6, 2011 at 9:14 PM, Paolo Bonzini pbonz...@redhat.com wrote:
GStreamer (V4L), RTSAdmin (LIO target), sg3_utils, trousers all are out of
tree, and nobody of their authors is even thinking of doing all this
brouhaha to get merged into Linus's tree.
We'd be the first subsystem to use
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini pbonz...@redhat.com wrote:
If you're bisecting breakage that can be in the guest kernel or the
KVM tool, you'd want to build both.
No. I want to try new tool/old kernel and old tool/new kernel (kernel can
be either guest or host, depending on
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Nothing, but I'm just giving you *strong* hints that a submodule or a merged
tool is the wrong solution, and the histories of kernel and tool should be
kept separate.
And btw, I don't really understand what you're trying
On Mon, Nov 7, 2011 at 8:29 AM, Sasha Levin levinsasha...@gmail.com wrote:
As you said, clone() isn't really an option - sharing things like the VM
and handles is something which I want to avoid. How does your patch
handle IPC?
Use the unshare() system call?
--
To unsubscribe from this list:
On Sun, 6 Nov 2011, Ted Ts'o wrote:
The only excuse I can see is a hope to make random changes to the
kernel and userspace tools without having to worry about compatibility
problems, which is an argument I've seen with perf (that you have to
use the same version of perf as the kernel version,
Hi Anthony,
On Sun, 6 Nov 2011, Anthony Liguori wrote:
- Drop SDL/VNC. Make a proper Cairo GUI with a full blown GTK interface.
Don't rely on virt-manager for this. Not that I have anything against
virt-manager but there are many layers between you and the end GUI if you go
that route.
On Mon, Nov 7, 2011 at 12:08 AM, Frank Ch. Eigler f...@redhat.com wrote:
[...] We don't want to be different, we want to make the barrier of
entry low.
When has the barrier of entry into the kernel ever been low
for anyone not already working in the kernel?
What's your point? Working on the
201 - 300 of 746 matches
Mail list logo
