http://blog.gmane.org/gmane.linux.kernel.virtualization.lguest hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1250 <pre>Hello all! I want to add a serial port to lguest as part of a bigger project. Problem is I can't even launch it for the past three weeks. i am using this cmd: sudo ~/src/linux-2.6.32/Documentation/lguest/lguest 64 ~/src/linux-2.6.32/vmlinux --tunnet=192.168.19.1 --block=/home/borod/lg/initrd-1.1-i386.img root=/dev/vda [ 0.000000] Reserving virtual address space above 0xffc00000 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.32.46+drm33.20 (borod&lt; at &gt;borod-laptop) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #1 SMP Wed Dec 14 03:17:21 IST 2011 (Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2) [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] NSC Geode by NSC [ 0.000000] Cyrix CyrixInstead [ 0.000000] Centaur CentaurHauls [ 0.000000] Transmeta GenuineTMx86 [ 0.000000] Transmeta TransmetaCPU [ 0.000000] UMC UMC UMC UMC [ 0.0000</pre> Boris Od 2011-12-24T10:31:28 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1249 <pre> Hi All, Until now I used Lguest for research purposes on an intel atom 32bit platform. Now I want to use it on an i5 machine, which is a 64bit platform but the kernel i use (3.0.9) is compiled for i686. I configured lguest the same as before, but I get lguest: unhandled trap 13 at 0x100062 (0x0) when the Launcher process starts. Does lguest does not work on a 64bit platform although the kernel is 32 bit? The .config file is attached. Your help would be much appreciated as it would help my research very much. Thank you and best regards, Eugene _______________________________________________ Lguest mailing list Lguest-uLR06cmDAlY/bJ5BZ2RsiQ&lt; at &gt;public.gmane.org https://lists.ozlabs.org/listinfo/lguest </pre> Eugene Kov 2011-12-16T15:50:03 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1247 <pre>OK, it's been a while ... I"ve built lguest on my chromebook. It's an i686 kernel of course. The location is at 1371e36 which I realize means nothing but ... it's in default_entry. It also looks to me like it's long before virtual addressing is turned on. Things have changed in the kernel in this particular area so I am not as familiar with it as I was (and soon will be, again ...) Could this be some simple screwup on configuration or something I have to tell lguest somehow? The command is simple: lguest 64m vmlinux I realize I need a root but I want to see it get far enough to explode. I like fireworks. thanks for any good hints ... And, yes, config is set as in the doc, with CONFIG_PARAVIRT=y, CONFIG_LGUEST_GUEST=y, ..EXPERIMENTAL=y, HIGHMEM64G=n, and so on. I think I'm doing something dumb, just not sure what ... memory fails me. thanks ron </pre> ron minnich 2012-01-14T05:57:42 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1234 <pre>I cannot seem to find the original lguest for ARM branch in the current working lguest tree (which as far as I can tell, should be Rusty's tree on kernel.org or github). It would appear that this branch was not moved over following the kernel.org breach. Am I right in assuming that this was the failure and where can I find a copy of the code for that? Thanks, William Cunningham Junior, Computer Engineering University of Michigan _______________________________________________ Lguest mailing list Lguest-uLR06cmDAlY/bJ5BZ2RsiQ&lt; at &gt;public.gmane.org https://lists.ozlabs.org/listinfo/lguest </pre> William Cunningham 2011-11-28T05:47:13 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1230 <pre>Hi All, Is there a reason why the Documentation directrory does not contain the "lguest" directory (with the launcher program)? Will the launcher from previouse releases would work? Regards, Eviatar </pre> Eviatar Khen 2011-12-03T07:53:55 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1223 <pre>Hello, What is the status of lguest on x86_64 ? I know that 3 years ago, there was an effort to port lguest on this architecture, but isn't very clear what happened since then. thanks, Daniel. </pre> Daniel Baluta 2011-10-06T15:05:01 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1219 <pre>Hello, first i would like to say thanks for the fantastic lguest hypervisor :) Im testing the lguest arm patch, after some issues using the patched kernel tree given by the board builder , i have found that using some commands inside the guest crashes the host. running reboot -f, crashes the board. and running a dummy test like this while [ 1 ]; do dd if=/bin/busybox of=/teste.bin; sleep 1 ; done 1910+1 records in 1910+1 records out 978416 bytes (955.5KB) copied, Illegal instruction What is the current state of the arm patch? Im asking because i not sure if the issue is the current state of the arm patch, or my clumsy merge work :) At this moment testing with a small ramfs image, on a OMAP3 My board is an igep2 http://www.igep.es/ PS: A big thank you for the arm patch author! Thanks in advance Nuno _______________________________________________ Lguest mailing list Lguest-uLR06cmDAlY/bJ5BZ2RsiQ&lt; at &gt;public.gmane.org https://lists.ozlabs.org/listinfo/lguest </pre> Nuno Felicio 2011-07-25T10:18:39 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1203 <pre>Hi, I've seen a bunch of cases where the guest just disappears and I see kernel messages such as the one in the associated patch. The reasons for these are allocation failures (at least in my case) and they are quite sporadic. The guests may stay up for three months and then run into one. I guess ignoring these errors is the best way to treat them. The patch still prints a warning message when one happens but makes the lguest process not to exit as a consequence. The reason I'm sending this as an RFC is: should all kinds of non-succesful results considered warnings in these cases, or should some still be considered as errors? Should also other than the obvious errors in system calls be treated as warnings only? All errors that have caused the guest to quit I've seen so far are from writev() in net_output(). I think I'm probably getting at least ENOBUFS (from sock_alloc_send_pskb) but I still need to check that. The patch I've been testing didn't print the error numbers until very recently. </pre> Sakari Ailus 2011-06-26T16:36:33 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1194 <pre>OK, different people seem to test different trees. In the hope to get everyone on the same page, I created several variants of this patch so they can be compared. Whoever's interested, please check out the following, and tell me how these compare: kernel: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git virtio-net-limit-xmit-polling/base - this is net-next baseline to test against virtio-net-limit-xmit-polling/v0 - fixes checks on out of capacity virtio-net-limit-xmit-polling/v1 - previous revision of the patch this does xmit,free,xmit,2*free,free virtio-net-limit-xmit-polling/v2 - new revision of the patch this does free,xmit,2*free,free There's also this on top: virtio-net-limit-xmit-polling/v3 -&gt; don't delay avail index update I don't think it's important to test this one, yet Userspace to use: event index work is not yet merged upstream so the revision to use is still this: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git virtio-net-event-idx-v3 </pre> Michael S. Tsirkin 2011-06-19T10:27:00 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1186 <pre>Hello, I have a slackware 13.37 distribution with a 2.6.37.6 kernel. lguest seems unable to launch on low mem: $ ./lguest-2.6.37.6 16 --block slack.img bzImage-2.6.37.6 ro root=/dev/vda1 lguest-2.6.37.6: unhandled trap 14 at 0x10003d (0x214bb7c) With more mem it's OK: $ ./lguest-2.6.37.6 48 --block slack.img bzImage-2.6.37.6 ro root=/dev/vda1 (taking some time, then ) [ 0.000000] Reserving virtual address space above 0xffc00000 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu (and so on) So, is there a minimum RAM requirement for lguest? Thanks Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com </pre> octane indice 2011-06-08T12:31:52 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1167 <pre>OK, here's a new attempt to use the new capacity api. I also added more comments to clarify the logic. Hope this is more readable. Let me know pls. This is on top of the patches applied by Rusty. Warning: untested. Posting now to give people chance to comment on the API. Changes from v1: - fix comment in patch 2 to correct confusion noted by Rusty - rewrite patch 3 along the lines suggested by Rusty note: it's not exactly the same but I hope it's close enough, the main difference is that mine does limited polling even in the unlikely xmit failure case. - added a patch to not return capacity from add_buf it always looked like a weird hack Michael S. Tsirkin (4): virtio_ring: add capacity check API virtio_net: fix tx capacity checks using new API virtio_net: limit xmit polling Revert "virtio: make add_buf return capacity remaining: drivers/net/virtio_net.c | 111 ++++++++++++++++++++++++++---------------- drivers/virtio/virtio_ring.c | 10 +++- include/linux/virtio.h | </pre> Michael S. Tsirkin 2011-06-02T15:42:35 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1153 <pre>OK, here's a new attempt to use the new capacity api. I also added more comments to clarify the logic. Hope this is more readable. Let me know pls. This is on top of the patches applied by Rusty. Note: there are now actually 2 calls to fee_old_xmit_skbs on data path so instead of passing flag '2' to the second one I thought we can just make each call free up at least 1 skb. This will work and even might be a bit faster (less branches), but in the end I discarded this idea as too fragile (relies on two calls on data path to function properly). Warning: untested. Posting now to give people chance to comment on the API. Michael S. Tsirkin (3): virtio_ring: add capacity check API virtio_net: fix tx capacity checks using new API virtio_net: limit xmit polling drivers/net/virtio_net.c | 65 +++++++++++++++++++++++------------------ drivers/virtio/virtio_ring.c | 8 +++++ include/linux/virtio.h | 5 +++ 3 files changed, 49 insertions(+), 29 deletions(-) </pre> Michael S. Tsirkin 2011-06-01T09:49:37 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1119 <pre>I saw the FIXME while reading the lguest documentation, and ... I tried to fix it. :) I think we only have to check for -ENOMEM, since all the other return values are harmless (ie -EEXIST) and -EINVAL cannot be returned (normally). Signed-off-by: Stratos Psomadakis &lt;psomas-Hpc4xzY4zrDSDkk6z29a7FAUjnlXr6A1&lt; at &gt;public.gmane.org&gt; --- arch/x86/lguest/boot.c | 15 ++++++++++----- drivers/lguest/lguest_device.c | 6 ++++-- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c index 1cd6089..fd392e7 100644 --- a/arch/x86/lguest/boot.c +++ b/arch/x86/lguest/boot.c &lt; at &gt;&lt; at &gt; -840,15 +840,20 &lt; at &gt;&lt; at &gt; static void __init lguest_init_IRQ(void) * With CONFIG_SPARSE_IRQ, interrupt descriptors are allocated as-needed, so * rather than set them in lguest_init_IRQ we are called here every time an * lguest device needs an interrupt. - * - * FIXME: irq_alloc_desc_at() can fail due to lack of memory, we should - * pass that up! */ -void lguest_setup_irq(unsigned in</pre> Stratos Psomadakis 2011-05-19T11:33:02 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1116 <pre>OK, here's a patch that implements the virtio spec update that I sent earlier. It supercedes the PUBLISH_USED_IDX patches I sent out earlier. Support is added in both userspace and vhost-net. If you see issues or are just curious, you can turn the new feature off. For example: -global virtio-net-pci.event_idx=on -global virtio-blk-pci.event_idx=off Also, it's possible to try both vhost-net and virtio-net. Another part is adding support for 64 bit features in place. The high bits are actually unused, to test hack qemu to set some high bit. linux code is here: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next-event-idx-v3 git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git virtio-net-event-idx-v3 Changes from v1: - unify used and avail ring handling in a single feature bit - copy avail event idx fix from vhost-net Michael S. Tsirkin (2): virtio/vhost: support 64 bit features virtio+vhost: event idx feature hw/qdev-properties.c | 39 +++++++++++++--- hw/qde</pre> Michael S. Tsirkin 2011-05-19T23:24:00 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1102 <pre>OK, here is the large patchset that implements the virtio spec update that I sent earlier (the spec itself needs a minor update, will send that out too next week, but I think we are on the same page here already). It supercedes the PUBLISH_USED_IDX patches I sent out earlier. What will follow will be a patchset that actually includes 4 sets of patches. I note below their status. Please consider for 2.6.40, at least partially. Rusty, do you think it's feasible? List of patches and what they do: I) With the first patchset, we change virtio ring notification hand-off to work like the one in Xen - each side publishes an event index, the other one notifies when it reaches that value - With the one difference that event index starts at 0, same as request index (in xen event index starts at 1). These are the patches in this set: virtio: event index interface virtio ring: inline function to check for events virtio_ring: support event idx feature vhost: support event index virtio_test: support event index Chan</pre> Michael S. Tsirkin 2011-05-19T23:10:07 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1082 <pre>Extend features to 64 bit so we can use more transport bits. Future patches add two new feature bits which would exhaust the supply of transport feature bits, so let's add bit 31 to tell the guest that there are now 64 worth of features. For PCI this also changes the config layout. Signed-off-by: Michael S. Tsirkin &lt;mst-H+wXaHxf7aLQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; --- drivers/lguest/lguest_device.c | 8 ++++---- drivers/s390/kvm/kvm_virtio.c | 6 +++--- drivers/virtio/virtio.c | 8 ++++---- drivers/virtio/virtio_pci.c | 33 +++++++++++++++++++++++++++------ include/linux/virtio.h | 2 +- include/linux/virtio_config.h | 15 +++++++++------ include/linux/virtio_pci.h | 9 ++++++++- 7 files changed, 56 insertions(+), 25 deletions(-) diff --git a/drivers/lguest/lguest_device.c b/drivers/lguest/lguest_device.c index 69c84a1..d2d6953 100644 --- a/drivers/lguest/lguest_device.c +++ b/drivers/lguest/lguest_device.c &lt; at &gt;&lt; at &gt; -93,17 +93,17 &lt; at &gt;&lt; at &gt; static unsigned desc_size(const struct</pre> Michael S. Tsirkin 2011-04-11T16:55:25 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1036 <pre> Hi, I am trying to call set_thread_area() (syscall(243, ) in lguest guest machine, and I am getting: [ 81.364146] set_thread_area[848] general protection ip:b7f1d5db sp:bfaac13c error:0 in ld-2.11.2.so[b7f10000+1b000] I tried it in debian 2.6.30 and kernel.org's 2.6.36 (Segmentation fault) kernel but got the same result. I am running the set_thread_area02.c from: http://ossipedia.ipa.go.jp/crackerjack/cjk/system_calls/265.html #include &lt;stdio.h&gt; #include &lt;errno.h&gt; #include &lt;linux/unistd.h&gt; #include &lt;asm/ldt.h&gt; int main(int ac, char **av) { struct user_desc u_info; u_info.entry_number = 6; int result = syscall(244, &amp;u_info); //call get_thread_area() if(result == -1) { printf("FAIL ------ call get_thread_area() failed with errno:%d\n", errno); return -1; } u_info.entry_number = -1; result = syscall(243, &amp;u_info); //call set_thread_area() if(result == 0) { printf("PASS ------ \n"); return 0; } else { </pre> Elisha Choe 2011-02-17T18:53:53 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1034 <pre>Hi all, I could use some ideas for the following problem. I need that running guests would have the ability to answer the question: am I guest of type X or not? The launcher needs to decide whether the guest is X or not, and the guest should conclude this while running. Using a hypercall would not work because that current hypercall mechanism does not return a value (actually it returns that hypercall number). The only idea that I have is put an indication ,if the guest is X or not, somewhere in a physical address that would be foreknown to both the launcher and the guest. I think that this requires writing some assembly code which I prefer to avoid. Does anyone have some other ideas? Thank you and best regards, Eviatar </pre> Eviatar Khen 2011-02-01T16:18:42 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1033 <pre>The following changes since commit 8a335bc631ac9c43675821580c26ebf95a3044ba: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/scsi-post-merge-2.6 (2011-01-16 15:06:43 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Christoph Lameter (1): lguest: Use this_cpu_ops Milton Miller (1): virtio: remove virtio-pci root device Philip Sanderson (3): lguest: --username and --chroot options lguest: example launcher to use guard pages, drop PROT_EXEC, fix limit logic lguest: document --rng in example Launcher Randy Dunlap (1): LGUEST_GUEST: fix unmet direct dependencies (VIRTUALIZATION &amp;&amp; VIRTIO) Rusty Russell (1): lguest: compile fixes Documentation/lguest/lguest.c | 73 ++++++++++++++++++++++++++++++++++---- Documentation/lguest/lguest.txt | 5 +++ arch/x86/lguest/Kconfig | 1 + arch/x86/lguest/boot.c | 2 +- drivers/lgues</pre> Rusty Russell 2011-01-20T11:13:31 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1031 <pre>Hi all, I want to add a function for the guest to use, that is capable of reading a field in the lguest_data structure (located in the guest memory). I will explain why (so maybe there is some other way...). The guest is a making some new hypercall to the hypervisor. The hypervisor changes some configuration of the guest (let's say in lguest_data). When the guest's control returns I want him to act with respect to the changed configuration, for instance: if (lguest_data-&gt;child) return 0; else return 1; AFAIK accessing lguest_data from the guest is only possible from arch/x86/lguest/boot.c, but I don't want to put my function in there. What I need is something similar to a virtqueues - an address in memory that is accessible both from guest and host, but all I need is a single byte and not all the virtqueue infrastructure. Ideas would be much help to me. Thanks, Eviatar </pre> eviatar 2011-01-14T11:30:55 http://comments.gmane.org/gmane.linux.kernel.virtualization.lguest/1030 <pre>Hello, We would like to add hypercall for forking the guest on lguest subsystem. Our goal is to have two identical guests. (Our goal is to develop module for code coverage) We added an hypercall to "fork-myself" (hypercall 20) and when we receive the hypercall (in the run_guest main loop) we exit to the launcher with a special return value. upon receiving this return value we fork the launcher process and copy the lguest structure. We are then able to continue running in the original process but not the child. Our child hangs when it printks. It never gets beyond the first notify hypercall. Questions 1) When calling fork we replicate the guest process (including VM) but not the cloned do_thread processes with CLONE_VM. We considered the process as stuck however, the do_thread process for IO (console output) is able to read data... this puzzles us because the process was created with fork not clone so we don't understand why console_output is able to read from the child virtQ. Does it make sense? can t</pre> Nezer Zaidenberg 2011-01-09T08:01:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.virtualization.lguest