gmane.linux.kernel.virtualization.lguest

lguest launch hangs on "Marking TSC..."

Boris Od — 2011-12-24T10:31:28

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< at >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.000000] BIOS-provided physical RAM map:
[    0.000000]  LGUEST: 0000000000000000 - 0000000004000000 (usable)
[    0.000000] DMI not present or invalid.
[    0.000000] last_pfn = 0x4000 max_arch_pfn = 0x100000
[    0.000000] Scanning 2 areas for low memory corruption
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000002000 (usable)
[    0.000000]  modified: 0000000000002000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 0000000000007000 (usable)
[    0.000000]  modified: 0000000000007000 - 0000000000010000 (reserved)
[    0.000000]  modified: 0000000000010000 - 0000000004000000 (usable)
[    0.000000] init_memory_mapping: 0000000000000000-0000000004000000
[    0.000000] Using x86 segment limits to approximate NX protection
[    0.000000] 0MB HIGHMEM available.
[    0.000000] 64MB LOWMEM available.
[    0.000000]   mapped low ram: 0 - 04000000
[    0.000000]   low ram: 0 - 04000000
[    0.000000]   node 0 low ram: 00000000 - 04000000
[    0.000000]   node 0 bootmap 00021000 - 00021800
[    0.000000] (6 early reservations) ==> bootmem [0000000000 - 0004000000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page ==>
[0000000000 - 0000001000]
[    0.000000]   #1 [0000001000 - 0000002000]    EX TRAMPOLINE ==>
[0000001000 - 0000002000]
[    0.000000]   #2 [0000006000 - 0000007000]       TRAMPOLINE ==>
[0000006000 - 0000007000]
[    0.000000]   #3 [0000100000 - 00008f5f58]    TEXT DATA BSS ==>
[0000100000 - 00008f5f58]
[    0.000000]   #4 [0000010000 - 0000021000]          PGTABLE ==>
[0000010000 - 0000021000]
[    0.000000]   #5 [0000021000 - 0000022000]          BOOTMAP ==>
[0000021000 - 0000022000]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   Normal   0x00001000 -> 0x00004000
[    0.000000]   HighMem  0x00004000 -> 0x00004000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00000002
[    0.000000]     0: 0x00000006 -> 0x00000007
[    0.000000]     0: 0x00000010 -> 0x00004000
[    0.000000] Using APIC driver default
[    0.000000] SFI: Simple Firmware Interface v0.7 http://simplefirmware.org
[    0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs
[    0.000000] No local APIC present or hardware disabled
[    0.000000] APIC: disable apic facility
[    0.000000] PM: Registered nosave memory: 0000000000002000 -
0000000000006000
[    0.000000] PM: Registered nosave memory: 0000000000007000 -
0000000000010000
[    0.000000] Allocating PCI resources starting at 4000000 (gap:
4000000:fc000000)
[    0.000000] Booting paravirtualized kernel on lguest
[    0.000000] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1
[    0.000000] PERCPU: Embedded 14 pages/cpu < at >c1084000 s34936 r0 d22408
u65536
[    0.000000] pcpu-alloc: s34936 r0 d22408 u65536 alloc=16*4096
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 16243
[    0.000000] Kernel command line: root=/dev/vda
[    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Enabling fast FPU save and restore... done.
[    0.000000] Enabling unmasked SIMD FPU exception support... done.
[    0.000000] Initializing CPU#0
[    0.000000] allocated 327680 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want
memory cgroups
[    0.000000] Initializing HighMem for node 0 (00000000:00000000)
[    0.000000] Memory: 56260k/65536k available (4738k kernel code, 9200k
reserved, 2154k data, 664k init, 0k highmem)
[    0.000000] virtual kernel memory layout:
[    0.000000]     fixmap  : 0xffb1d000 - 0xffbff000   ( 904 kB)
[    0.000000]     pkmap   : 0xff400000 - 0xff800000   (4096 kB)
[    0.000000]     vmalloc : 0xc4800000 - 0xff3fe000   ( 939 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
[    0.000000]       .init : 0xc07bc000 - 0xc0862000   ( 664 kB)
[    0.000000]       .data : 0xc05a0bd5 - 0xc07bb668   (2154 kB)
[    0.000000]       .text : 0xc0100000 - 0xc05a0bd5   (4738 kB)
[    0.000000] Checking if this processor honours the WP bit even in
supervisor mode...Ok.
[    0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0,
CPUs=1, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:2304 nr_irqs:256
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [hvc0] enabled
[    0.000000] Trying to install interrupt handler for IRQ0
[    0.000000] Marking TSC unstable due to could not calculate TSC khz


and then hangs.

Could not find a solution, will be very grateful for your help.

Thank You.
Boris.
_______________________________________________
Lguest mailing list
Lguest-uLR06cmDAlY/bJ5BZ2RsiQ< at >public.gmane.org
https://lists.ozlabs.org/listinfo/lguest

Lguest on i5

Eugene Kov — 2011-12-16T15:50:03

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< at >public.gmane.org
https://lists.ozlabs.org/listinfo/lguest

problem on 3.0.13: unhandled trap 13 at 0x1371e36 (0x0)

ron minnich — 2012-01-14T05:57:42

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

lguest for ARM

William Cunningham — 2011-11-28T05:47:13

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< at >public.gmane.org
https://lists.ozlabs.org/listinfo/lguest

Documentation/lguest in kernel 3.0

Eviatar Khen — 2011-12-03T07:53:55

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

Lguest on x86_64

Daniel Baluta — 2011-10-06T15:05:01

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.

Current state of the lguest arm patch

Nuno Felicio — 2011-07-25T10:18:39

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< at >public.gmane.org
https://lists.ozlabs.org/listinfo/lguest

[RFC/PATCH 0/1] lguest: Ignore non-fatal errors

Sakari Ailus — 2011-06-26T16:36:33

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.

RFT: virtio_net: limit xmit polling

Michael S. Tsirkin — 2011-06-19T10:27:00

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 -> 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

unhandled trap 14 for low mem?

octane indice — 2011-06-08T12:31:52

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

[PATCHv2 RFC 0/4] virtio and vhost-net capacity handling

Michael S. Tsirkin — 2011-06-02T15:42:35

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       |    7 ++-
 3 files changed, 84 insertions(+), 44 deletions(-)

[PATCH RFC 0/3] virtio and vhost-net capacity handling

Michael S. Tsirkin — 2011-06-01T09:49:37

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(-)

[PATCH] lguest: Make sure the interrupt is allocatedcorrectly by lguest_setup_irq (ie check the return value ofirq_alloc_desc_at for -ENOMEM)

Stratos Psomadakis — 2011-05-19T11:33:02

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 <psomas-Hpc4xzY4zrDSDkk6z29a7FAUjnlXr6A1< at >public.gmane.org>
---
 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
< at >< at > -840,15 +840,20 < at >< at > 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 int irq)
+int lguest_setup_irq(unsigned int irq)
 {
-irq_alloc_desc_at(irq, 0);
+int err = 0;
+
+err = irq_alloc_desc_at(irq, 0);
+if (err  == -ENOMEM)
+goto out;
+
 irq_set_chip_and_handler_name(irq, &lguest_irq_controller,
       handle_level_irq, "level");
+
+out:
+return err;
 }
 
 /*
diff --git a/drivers/lguest/lguest_device.c b/drivers/lguest/lguest_device.c
index 69c84a1..3fadfe5 100644
--- a/drivers/lguest/lguest_device.c
+++ b/drivers/lguest/lguest_device.c
< at >< at > -233,7 +233,7 < at >< at > static void lg_notify(struct virtqueue *vq)
 }
 
 /* An extern declaration inside a C file is bad form.  Don't do it. */
-extern void lguest_setup_irq(unsigned int irq);
+extern int lguest_setup_irq(unsigned int irq);
 
 /*
  * This routine finds the Nth virtqueue described in the configuration of
< at >< at > -294,7 +294,9 < at >< at > static struct virtqueue *lg_find_vq(struct virtio_device *vdev,
 }
 
 /* Make sure the interrupt is allocated. */
-lguest_setup_irq(lvq->config.irq);
+err = lguest_setup_irq(lvq->config.irq);
+if (err == -ENOMEM)
+goto unmap;
 
 /*
  * Tell the interrupt for this virtqueue to go to the virtio_ring

[PATCHv2 0/2] virtio-net: 64 bit features, event index

Michael S. Tsirkin — 2011-05-19T23:24:00

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/qdev.h              |   10 ++++
 hw/s390-virtio-bus.c   |    5 +-
 hw/s390-virtio-bus.h   |    2 +-
 hw/syborg_virtio.c     |    7 ++-
 hw/vhost_net.c         |   14 ++++--
 hw/vhost_net.h         |    4 +-
 hw/virtio-9p.c         |    2 +-
 hw/virtio-balloon.c    |    2 +-
 hw/virtio-blk.c        |    2 +-
 hw/virtio-blk.h        |    2 +-
 hw/virtio-net.c        |   11 +++--
 hw/virtio-net.h        |   34 +++++++-------
 hw/virtio-pci.c        |   91 +++++++++++++++++++++++++++----------
 hw/virtio-serial-bus.c |    2 +-
 hw/virtio.c            |  116 ++++++++++++++++++++++++++++++++++++++++++------
 hw/virtio.h            |   24 +++++++---
 17 files changed, 275 insertions(+), 92 deletions(-)

[PATCHv2 00/14] virtio and vhost-net performanceenhancements

Michael S. Tsirkin — 2011-05-19T23:10:07

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

Changes in this part of the patchset from v1 - address comments by Rusty et al.

I tested this a lot with virtio net block and with the simulator and esp
with the simulator it's easy to see drastic performance improvement
here:

[virtio]# time ./virtio_test 
spurious wakeus: 0x7

real    0m0.169s
user    0m0.140s
sys     0m0.019s
[virtio]# time ./virtio_test --no-event-idx
spurious wakeus: 0x11

real    0m0.649s
user    0m0.295s
sys     0m0.335s

And these patches are mostly unchanged from the very first version,
changes being almost exclusively code cleanups.  So I consider this part
the most stable, I strongly think these patches should go into 2.6.40.
One extra reason besides performance is that maintaining
them out of tree is very painful as guest/host ABI is affected.

II) Second set of patches: new apis and use in virtio_net
With the indexes in place it becomes possibile to request an event after
many requests (and not just on the next one as done now). This shall fix
the TX queue overrun which currently triggers a storm of interrupts.

Another issue I tried to fix is capacity checks in virtio-net,
there's a new API for that, and on top of that,
I implemented a patch improving real-time characteristics
of virtio_net

Thus we get the second patchset:
virtio: add api for delayed callbacks
virtio_net: delay TX callbacks
virtio_ring: Add capacity check API
virtio_net: fix TX capacity checks using new API
virtio_net: limit xmit polling

This has some fixes that I posted previously applied,
but otherwise ideantical to v1. I tried to change API
for enable_cb_delayed as Rusty suggested but failed to do this.
I think it's not possible to define cleanly.

These work fine for me, I think they can be merged for 2.6.40
too but would be nice to hear back from Shirley, Tom, Krishna.

III) There's also a patch that adds a tweak to virtio ring
virtio: don't delay avail index update

This seems to help small message sizes where we are constantly draining
the RX VQ.

I'll need to benchmark this to be able to give any numbers
with confidence, but I don't see how it can hurt anything.
Thoughts?

IV) Last part is a set of patches to extend feature bits
to 64 bit. I tested this by using feature bit 32.
vhost: fix 64 bit features
virtio_test: update for 64 bit features
virtio: 64 bit features

It's nice to have as set I used up the last free bit.
But not a must now that a single bit controls
use of event index on both sides.

The patchset is on top of net-next which at the time
I last rebased was 15ecd03 - so roughly 2.6.39-rc2.
For testing I usually do merge v2.6.39 on top.

qemu patch is also ready.  Code can be pulled from 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

Rusty, I think it will be easier to merge vhost and virtio bits in one
go. Can it all go in through your tree (Dave in the past acked
sending a very similar patch through you so should not be a problem)?

[RFC][PATCH] virtio: 64 bit features

Michael S. Tsirkin — 2011-04-11T16:55:25

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 <mst-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
---
 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
< at >< at > -93,17 +93,17 < at >< at > static unsigned desc_size(const struct lguest_device_desc *desc)
 }
 
 /* This gets the device's feature bits. */
-static u32 lg_get_features(struct virtio_device *vdev)
+static u64 lg_get_features(struct virtio_device *vdev)
 {
 unsigned int i;
-u32 features = 0;
+u64 features = 0;
 struct lguest_device_desc *desc = to_lgdev(vdev)->desc;
 u8 *in_features = lg_features(desc);
 
 /* We do this the slow but generic way. */
-for (i = 0; i < min(desc->feature_len * 8, 32); i++)
+for (i = 0; i < min(desc->feature_len * 8, 64); i++)
 if (in_features[i / 8] & (1 << (i % 8)))
-features |= (1 << i);
+features |= (1ull << i);
 
 return features;
 }
diff --git a/drivers/s390/kvm/kvm_virtio.c b/drivers/s390/kvm/kvm_virtio.c
index 414427d..8c976d0 100644
--- a/drivers/s390/kvm/kvm_virtio.c
+++ b/drivers/s390/kvm/kvm_virtio.c
< at >< at > -82,13 +82,13 < at >< at > static unsigned desc_size(const struct kvm_device_desc *desc)
 static u32 kvm_get_features(struct virtio_device *vdev)
 {
 unsigned int i;
-u32 features = 0;
+u64 features = 0;
 struct kvm_device_desc *desc = to_kvmdev(vdev)->desc;
 u8 *in_features = kvm_vq_features(desc);
 
-for (i = 0; i < min(desc->feature_len * 8, 32); i++)
+for (i = 0; i < min(desc->feature_len * 8, 64); i++)
 if (in_features[i / 8] & (1 << (i % 8)))
-features |= (1 << i);
+features |= (1ull << i);
 return features;
 }
 
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index efb35aa..52b24d7 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
< at >< at > -112,7 +112,7 < at >< at > static int virtio_dev_probe(struct device *_d)
 struct virtio_device *dev = container_of(_d,struct virtio_device,dev);
 struct virtio_driver *drv = container_of(dev->dev.driver,
  struct virtio_driver, driver);
-u32 device_features;
+u64 device_features;
 
 /* We have a driver! */
 add_status(dev, VIRTIO_CONFIG_S_DRIVER);
< at >< at > -124,14 +124,14 < at >< at > static int virtio_dev_probe(struct device *_d)
 memset(dev->features, 0, sizeof(dev->features));
 for (i = 0; i < drv->feature_table_size; i++) {
 unsigned int f = drv->feature_table[i];
-BUG_ON(f >= 32);
-if (device_features & (1 << f))
+BUG_ON(f >= 64);
+if (device_features & (1ull << f))
 set_bit(f, dev->features);
 }
 
 /* Transport features always preserved to pass to finalize_features. */
 for (i = VIRTIO_TRANSPORT_F_START; i < VIRTIO_TRANSPORT_F_END; i++)
-if (device_features & (1 << i))
+if (device_features & (1ull << i))
 set_bit(i, dev->features);
 
 dev->config->finalize_features(dev);
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index 4fb5b2b..2a2ee72 100644
--- a/drivers/virtio/virtio_pci.c
+++ b/drivers/virtio/virtio_pci.c
< at >< at > -44,6 +44,8 < at >< at > struct virtio_pci_device
 spinlock_t lock;
 struct list_head virtqueues;
 
+/* 64 bit features */
+int features_hi;
 /* MSI-X support */
 int msix_enabled;
 int intx_enabled;
< at >< at > -103,26 +105,45 < at >< at > static struct virtio_pci_device *to_vp_device(struct virtio_device *vdev)
 }
 
 /* virtio config->get_features() implementation */
-static u32 vp_get_features(struct virtio_device *vdev)
+static u64 vp_get_features(struct virtio_device *vdev)
 {
 struct virtio_pci_device *vp_dev = to_vp_device(vdev);
+u32 flo, fhi;
 
-/* When someone needs more than 32 feature bits, we'll need to
+/* When someone needs more than 32 feature bits, we need to
  * steal a bit to indicate that the rest are somewhere else. */
-return ioread32(vp_dev->ioaddr + VIRTIO_PCI_HOST_FEATURES);
+flo = ioread32(vp_dev->ioaddr + VIRTIO_PCI_HOST_FEATURES);
+if (flo & (0x1 << VIRTIO_F_FEATURES_HI)) {
+vp_dev->features_hi = 1;
+iowrite32(0x1 << VIRTIO_F_FEATURES_HI,
+  vp_dev->ioaddr + VIRTIO_PCI_GUEST_FEATURES_HI);
+} else {
+vp_dev->features_hi = 0;
+}
+fhi = ioread32(vp_dev->ioaddr + VIRTIO_PCI_HOST_FEATURES_HI);
+return ((u64)fhi << 32) | flo;
 }
 
 /* virtio config->finalize_features() implementation */
 static void vp_finalize_features(struct virtio_device *vdev)
 {
 struct virtio_pci_device *vp_dev = to_vp_device(vdev);
+u32 flo, fhi;
 
 /* Give virtio_ring a chance to accept features. */
 vring_transport_features(vdev);
 
-/* We only support 32 feature bits. */
-BUILD_BUG_ON(ARRAY_SIZE(vdev->features) != 1);
-iowrite32(vdev->features[0], vp_dev->ioaddr+VIRTIO_PCI_GUEST_FEATURES);
+/* We only support 64 feature bits. */
+BUILD_BUG_ON(ARRAY_SIZE(vdev->features) != 64 / BITS_PER_LONG);
+flo = vdev->features[0];
+fhi = vdev->features[64 / BITS_PER_LONG - 1] >> (64 - BITS_PER_LONG);
+iowrite32(flo, vp_dev->ioaddr + VIRTIO_PCI_GUEST_FEATURES);
+if (flo & (0x1 << VIRTIO_F_FEATURES_HI)) {
+vp_dev->features_hi = 1;
+iowrite32(fhi, vp_dev->ioaddr + VIRTIO_PCI_GUEST_FEATURES_HI);
+} else {
+vp_dev->features_hi = 0;
+}
 }
 
 /* virtio config->get() implementation */
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index aff5b4f..718336b 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
< at >< at > -105,7 +105,7 < at >< at > struct virtio_device {
 struct virtio_config_ops *config;
 struct list_head vqs;
 /* Note that this is a Linux set_bit-style bitmap. */
-unsigned long features[1];
+unsigned long features[64 / BITS_PER_LONG];
 void *priv;
 };
 
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index 800617b..b1a1981 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
< at >< at > -18,16 +18,19 < at >< at >
 /* We've given up on this device. */
 #define VIRTIO_CONFIG_S_FAILED0x80
 
-/* Some virtio feature bits (currently bits 28 through 31) are reserved for the
+/* Some virtio feature bits (currently bits 28 through 39) are reserved for the
  * transport being used (eg. virtio_ring), the rest are per-device feature
  * bits. */
 #define VIRTIO_TRANSPORT_F_START28
-#define VIRTIO_TRANSPORT_F_END32
+#define VIRTIO_TRANSPORT_F_END40
 
 /* Do we get callbacks when the ring is completely used, even if we've
  * suppressed them? */
 #define VIRTIO_F_NOTIFY_ON_EMPTY24
 
+/* Enables feature bits 32 to 63 (only really required for virtio_pci). */
+#define VIRTIO_F_FEATURES_HI31
+
 #ifdef __KERNEL__
 #include <linux/err.h>
 #include <linux/virtio.h>
< at >< at > -72,7 +75,7 < at >< at >
  * < at >del_vqs: free virtqueues found by find_vqs().
  * < at >get_features: get the array of feature bits for this device.
  *vdev: the virtio_device
- *Returns the first 32 feature bits (all we currently need).
+ *Returns the first 64 feature bits (all we currently need).
  * < at >finalize_features: confirm what device features we'll be using.
  *vdev: the virtio_device
  *This gives the final feature bits for the device: it can change
< at >< at > -92,7 +95,7 < at >< at > struct virtio_config_ops {
 vq_callback_t *callbacks[],
 const char *names[]);
 void (*del_vqs)(struct virtio_device *);
-u32 (*get_features)(struct virtio_device *vdev);
+u64 (*get_features)(struct virtio_device *vdev);
 void (*finalize_features)(struct virtio_device *vdev);
 };
 
< at >< at > -110,9 +113,9 < at >< at > static inline bool virtio_has_feature(const struct virtio_device *vdev,
 {
 /* Did you forget to fix assumptions on max features? */
 if (__builtin_constant_p(fbit))
-BUILD_BUG_ON(fbit >= 32);
+BUILD_BUG_ON(fbit >= 64);
 else
-BUG_ON(fbit >= 32);
+BUG_ON(fbit >= 64);
 
 if (fbit < VIRTIO_TRANSPORT_F_START)
 virtio_check_driver_offered_feature(vdev, fbit);
diff --git a/include/linux/virtio_pci.h b/include/linux/virtio_pci.h
index 9a3d7c4..035b10e 100644
--- a/include/linux/virtio_pci.h
+++ b/include/linux/virtio_pci.h
< at >< at > -55,9 +55,16 < at >< at >
 /* Vector value used to disable MSI for queue */
 #define VIRTIO_MSI_NO_VECTOR            0xffff
 
+/* An extended 32-bit r/o bitmask of the features supported by the host */
+#define VIRTIO_PCI_HOST_FEATURES_HI0
+
+/* An extended 32-bit r/w bitmask of features activated by the guest */
+#define VIRTIO_PCI_GUEST_FEATURES_HI4
+
 /* The remaining space is defined by each driver as the per-driver
  * configuration space */
-#define VIRTIO_PCI_CONFIG(dev)((dev)->msix_enabled ? 24 : 20)
+#define VIRTIO_PCI_CONFIG(dev)((dev)->features_hi ? 32 : \
+(dev)->msix_enabled ? 24 : 20)
 
 /* Virtio ABI version, this must match exactly */
 #define VIRTIO_PCI_ABI_VERSION0

set_thread_area() fails in lguest

Elisha Choe — 2011-02-17T18:53:53




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 <stdio.h>
#include <errno.h>
#include <linux/unistd.h>
#include <asm/ldt.h>

int main(int ac, char **av)
{
    struct user_desc u_info;
    u_info.entry_number = 6;
    int result = syscall(244, &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, &u_info);        //call set_thread_area()
    if(result == 0)
    {
        printf("PASS ------ \n");
        return 0;
    }
    else
    {
        printf("FAIL ------ call set_thread_area() failed with errno:%d\n", errno);
        return -1;
    }
}

We are trying to run wine under lguest and this is the first problem we encountered.

Is this possible? Any suggestions in getting this to work?

Thank you

Elisha
       _______________________________________________
Lguest mailing list
Lguest-uLR06cmDAlY/bJ5BZ2RsiQ< at >public.gmane.org
https://lists.ozlabs.org/listinfo/lguest

Passing information from launcher to guest

Eviatar Khen — 2011-02-01T16:18:42

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

[PULL] lguest and virtio.

Rusty Russell — 2011-01-20T11:13:31

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 && 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/lguest/page_tables.c    |    2 +-
 drivers/lguest/x86/core.c       |    4 +-
 drivers/virtio/virtio_pci.c     |   20 +---------
 7 files changed, 77 insertions(+), 30 deletions(-)

accessing lguest_data from the guest

eviatar — 2011-01-14T11:30:55

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->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

Forking Guest on lguest system.

Nezer Zaidenberg — 2011-01-09T08:01:42

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 this be the reason we hang?

2) What is required from the virtQ so that the notify hypercall will complete? is it possible that we hang because the second notify is waiting on the virtQ on some condition that never occurs?

Any other ideas will be welcome

N