Menu
▾
▴
kvm-devel — kernel virtual machine development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(325) |
Dec
(320) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(484) |
Feb
(438) |
Mar
(407) |
Apr
(713) |
May
(831) |
Jun
(806) |
Jul
(1023) |
Aug
(1184) |
Sep
(1118) |
Oct
(1461) |
Nov
(1224) |
Dec
(1042) |
| 2008 |
Jan
(1449) |
Feb
(1110) |
Mar
(1428) |
Apr
(1643) |
May
(682) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Marcelo T. <mto...@re...> - 2008-04-22 02:59:10
|
Looks good. Does SCSI handle pci_register_device() failure too? Acked-by: Marcelo Tosatti <mto...@re...> On Mon, Apr 21, 2008 at 04:02:49PM -0700, Chris Wright wrote: > The pci_device_register() call in virtio_pci_init() can fail. > Handle this error condition instead of generating a SEGV. > > Cc: Marcelo Tosatti <mto...@re...> > Signed-off-by: Chris Wright <ch...@so...> > --- > qemu/hw/virtio-blk.c | 2 ++ > 1 file changed, 2 insertions(+) > > --- a/qemu/hw/virtio-blk.c > +++ b/qemu/hw/virtio-blk.c > @@ -163,6 +163,8 @@ void *virtio_blk_init(PCIBus *bus, uint1 > 0, VIRTIO_ID_BLOCK, > 0x01, 0x80, 0x00, > sizeof(struct virtio_blk_config), sizeof(VirtIOBlock)); > + if (!s) > + return NULL; > > s->vdev.update_config = virtio_blk_update_config; > s->vdev.get_features = virtio_blk_get_features; > > -- |
|
From: Nguyen A. Q. <aq...@gm...> - 2008-04-22 02:33:09
|
On Tue, Apr 22, 2008 at 12:59 AM, Damjan <gd...@ma...> wrote: > > > If I try > > > $ qemu -kernel minimal-kernel -drive file=jeos-devel.img,if=virtio > > > I get the following error: > > > A disk image must be given for 'hda' when booting a Linux kernel > > > is this neccesseary? > > > Hi, i don't know if it is always needed (I saw some patches to avoid > > that) but you can use: > > > > qemu -kernel minimal-kernel -drive file=jeos-devel.img,if=virtio -hda /dev/zero > > cool that works, thanks Try the linuxboot option ROM, and you might not need the trick "-hda /dev/zero" Thanks, Q |
|
From: Liu, E. E <eri...@in...> - 2008-04-22 02:21:58
|
Hollis Blanchard wrote:
> On Sunday 20 April 2008 00:38:32 Liu, Eric E wrote:
>> Christian Ehrhardt wrote:
>>> Liu, Eric E wrote:
>>>> Hollis Blanchard wrote:
>>>>> On Wednesday 16 April 2008 01:45:34 Liu, Eric E wrote: [...]
>>>>> Actually... we could have kvmtrace itself insert the metadata, so
>>>>> there would be no chance of it being overwritten in the kernel
>>>>> buffers. The header could be written in tip_open_output(), and
>>>>> update fs_size accordingly.
>>>>>
>>>> Yes, let kvmtrace insert the metadata is more reasonable.
>>>>
>>>
>>> I wanted to note that the kvmtrace tool should, but not need to know
>>> everything about the data format.
>>> I think of e.g. changing kernel implementations that change
>>> endianess or even flags we don't yet know, but we might need in the
>>> future.
>>>
>>> What about adding another debugfs entry the kernel can use to expose
>>> the "kvmtrace-metadata" defined by the kernel implementation.
>>> The kvmtrace tool could then use that to build up the record by
>>> using one entry for kernel defined metadata and another to add any
>>> metadata that would be defined by kvmtrace tool itself.
>>>
>>> what about that one:
>>> struct metadata {
>>> u32 kmagic; /* stores kernel defined metadata read from
debugfs
>>> entry */ u32 umagic; /* stores userspace tool defined
metadata */
>>> u32 extra; /* it is redundant, only use to fit into
record. */ }
>>>
>>> That should give us the flexibility to keep the format if we get
>>> more metadata requirements in the future.
>>
>> Yes, maybe we need metadata to indicate the changing kernel
>> implementations in the future, but adding debugfs entry seems not a
>> good approach. What about defining a similar metadat in kernel
>> rather than in userland and write it in rchan at the first time we
>> add trace data. Then we don't need kvmtrace tool to insert the
>> medadata again.
>> like this:
>> struct kvm_trace_metadata {
>> u32 kmagic; /* stores kernel defined metadata */
>> u64 extra; /* use to fit into record. */
>> }
>
> So you've gone back to the idea about the kernel inserting a special
> trace record? How do you handle the case where this record is
> overwritten before the logging app gets a chance to extract it? This
> issue is why I would prefer Christian's idea of a separate debugfs
> file (*not* relay channel) to export kernel flags.
>
Yes, seems my original idea not a good one, I agree with you and
Christian.
> At that point, kvmtrace can insert the flags in any way it wants. It
> doesn't need to appear as a trace record at all; it should simply be
> a header at the beginning of the trace file.
|
|
From: Chris W. <ch...@so...> - 2008-04-21 23:05:32
|
The pci_device_register() call in virtio_pci_init() can fail.
Handle this error condition instead of generating a SEGV.
Cc: Marcelo Tosatti <mto...@re...>
Signed-off-by: Chris Wright <ch...@so...>
---
qemu/hw/virtio-blk.c | 2 ++
1 file changed, 2 insertions(+)
--- a/qemu/hw/virtio-blk.c
+++ b/qemu/hw/virtio-blk.c
@@ -163,6 +163,8 @@ void *virtio_blk_init(PCIBus *bus, uint1
0, VIRTIO_ID_BLOCK,
0x01, 0x80, 0x00,
sizeof(struct virtio_blk_config), sizeof(VirtIOBlock));
+ if (!s)
+ return NULL;
s->vdev.update_config = virtio_blk_update_config;
s->vdev.get_features = virtio_blk_get_features;
--
|
|
From: Chris W. <ch...@so...> - 2008-04-21 23:05:32
|
The pci hotadd patches make it easy to trigger segfaults when adding more devices than a single PCI bus can handle. The following 2 patches fix the pci nic devices and virtio-blk device. Now the following the following: OK bus 0, slot 31, function 0 (devfn 248) (qemu) pci_add 0 nic model=virtio Segmentation fault OK bus 0, slot 31, function 0 (devfn 248) (qemu) pci_add 0 storage file=/mnt/disk1,if=virtio Segmentation fault become: OK bus 0, slot 31, function 0 (devfn 248) (qemu) pci_add 0 nic model=virtio qemu: Unable to initialze NIC: virtio failed to add model=virtio OK bus 0, slot 31, function 0 (devfn 248) (qemu) pci_add 0 storage file=/mnt/disk1,if=virtio failed to add file=/mnt/disk1,if=virtio thanks, -chris -- |
|
From: Chris W. <ch...@so...> - 2008-04-21 23:05:32
|
The pci_register_device() call in PCI nic initialization routines can
fail. Handle this failure and propagate a meaningful error message to
the user instead of generating a SEGV.
Cc: Marcelo Tosatti <mto...@re...>
Signed-off-by: Chris Wright <ch...@so...>
---
qemu/hw/e1000.c | 3 +++
qemu/hw/eepro100.c | 2 ++
qemu/hw/ne2000.c | 3 +++
qemu/hw/pci.c | 6 ++++++
qemu/hw/pcnet.c | 2 ++
qemu/hw/rtl8139.c | 3 +++
qemu/hw/virtio-net.c | 2 ++
qemu/hw/virtio.c | 3 +++
8 files changed, 24 insertions(+)
--- a/qemu/hw/e1000.c
+++ b/qemu/hw/e1000.c
@@ -963,6 +963,9 @@ pci_e1000_init(PCIBus *bus, NICInfo *nd,
d = (E1000State *)pci_register_device(bus, "e1000",
sizeof(E1000State), devfn, NULL, NULL);
+ if (!d)
+ return NULL;
+
pci_conf = d->dev.config;
memset(pci_conf, 0, 256);
--- a/qemu/hw/eepro100.c
+++ b/qemu/hw/eepro100.c
@@ -1753,6 +1753,8 @@ static PCIDevice *nic_init(PCIBus * bus,
d = (PCIEEPRO100State *) pci_register_device(bus, name,
sizeof(PCIEEPRO100State), -1,
NULL, NULL);
+ if (!d)
+ return NULL;
s = &d->eepro100;
s->device = device;
--- a/qemu/hw/ne2000.c
+++ b/qemu/hw/ne2000.c
@@ -796,6 +796,9 @@ PCIDevice *pci_ne2000_init(PCIBus *bus,
"NE2000", sizeof(PCINE2000State),
devfn,
NULL, NULL);
+ if (!d)
+ return NULL;
+
pci_conf = d->dev.config;
pci_conf[0x00] = 0xec; // Realtek 8029
pci_conf[0x01] = 0x10;
--- a/qemu/hw/pci.c
+++ b/qemu/hw/pci.c
@@ -696,6 +696,12 @@ PCIDevice *pci_nic_init(PCIBus *bus, NIC
fprintf(stderr, "qemu: Unsupported NIC: %s\n", nd->model);
return NULL;
}
+
+ if (!pci_dev) {
+ fprintf(stderr, "qemu: Unable to initialze NIC: %s\n", nd->model);
+ return NULL;
+ }
+
nd->devfn = pci_dev->devfn;
return pci_dev;
}
--- a/qemu/hw/pcnet.c
+++ b/qemu/hw/pcnet.c
@@ -1970,6 +1970,8 @@ PCIDevice *pci_pcnet_init(PCIBus *bus, N
d = (PCNetState *)pci_register_device(bus, "PCNet", sizeof(PCNetState),
devfn, NULL, NULL);
+ if (!d)
+ return NULL;
pci_conf = d->dev.config;
--- a/qemu/hw/rtl8139.c
+++ b/qemu/hw/rtl8139.c
@@ -3411,6 +3411,9 @@ PCIDevice *pci_rtl8139_init(PCIBus *bus,
"RTL8139", sizeof(PCIRTL8139State),
devfn,
NULL, NULL);
+ if (!d)
+ return NULL;
+
pci_conf = d->dev.config;
pci_conf[0x00] = 0xec; /* Realtek 8139 */
pci_conf[0x01] = 0x10;
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -292,6 +292,8 @@ PCIDevice *virtio_net_init(PCIBus *bus,
0, VIRTIO_ID_NET,
0x02, 0x00, 0x00,
6, sizeof(VirtIONet));
+ if (!n)
+ return NULL;
n->vdev.update_config = virtio_net_update_config;
n->vdev.get_features = virtio_net_get_features;
--- a/qemu/hw/virtio.c
+++ b/qemu/hw/virtio.c
@@ -408,6 +408,9 @@ VirtIODevice *virtio_init_pci(PCIBus *bu
pci_dev = pci_register_device(bus, name, struct_size,
-1, NULL, NULL);
+ if (!pci_dev)
+ return NULL;
+
vdev = to_virtio_device(pci_dev);
vdev->status = 0;
--
|
|
From: Anthony L. <an...@co...> - 2008-04-21 22:13:20
|
Jerone Young wrote: > virtio net device does not appear to show itself in the guest. I'm > curious of what options I may be missing. Here is my config You'll have to be more specific about what "does not appear to show itself" means. What's the output of lspci? Regards, Anthony Liguori > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ------------------------------------------------------------------------ > > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel |
|
From: Hollis B. <ho...@us...> - 2008-04-21 21:24:34
|
On Sunday 20 April 2008 00:38:32 Liu, Eric E wrote:
> Christian Ehrhardt wrote:
> > Liu, Eric E wrote:
> >> Hollis Blanchard wrote:
> >>> On Wednesday 16 April 2008 01:45:34 Liu, Eric E wrote: [...]
> >>> Actually... we could have kvmtrace itself insert the metadata, so
> >>> there would be no chance of it being overwritten in the kernel
> >>> buffers. The header could be written in tip_open_output(), and
> >>> update fs_size accordingly.
> >>>
> >> Yes, let kvmtrace insert the metadata is more reasonable.
> >>
> >
> > I wanted to note that the kvmtrace tool should, but not need to know
> > everything about the data format.
> > I think of e.g. changing kernel implementations that change endianess
> > or even flags we don't yet know, but we might need in the future.
> >
> > What about adding another debugfs entry the kernel can use to expose
> > the "kvmtrace-metadata" defined by the kernel implementation.
> > The kvmtrace tool could then use that to build up the record by using
> > one entry for kernel defined metadata and another to add any metadata
> > that would be defined by kvmtrace tool itself.
> >
> > what about that one:
> > struct metadata {
> > u32 kmagic; /* stores kernel defined metadata read from
> debugfs
> > entry */ u32 umagic; /* stores userspace tool defined
> metadata */
> > u32 extra; /* it is redundant, only use to fit into
> record. */
> > }
> >
> > That should give us the flexibility to keep the format if we get more
> > metadata requirements in the future.
>
> Yes, maybe we need metadata to indicate the changing kernel
> implementations in the future, but adding debugfs entry seems not a good
> approach. What about defining a similar metadat in kernel rather than in
> userland and write it in rchan at the first time we add trace data. Then
> we don't need kvmtrace tool to insert the medadata again.
> like this:
> struct kvm_trace_metadata {
> u32 kmagic; /* stores kernel defined metadata */
> u64 extra; /* use to fit into record. */
> }
So you've gone back to the idea about the kernel inserting a special trace
record? How do you handle the case where this record is overwritten before
the logging app gets a chance to extract it? This issue is why I would prefer
Christian's idea of a separate debugfs file (*not* relay channel) to export
kernel flags.
At that point, kvmtrace can insert the flags in any way it wants. It doesn't
need to appear as a trace record at all; it should simply be a header at the
beginning of the trace file.
--
Hollis Blanchard
IBM Linux Technology Center
|
|
From: Jerone Y. <jy...@us...> - 2008-04-21 21:24:33
|
virtio net device does not appear to show itself in the guest. I'm curious of what options I may be missing. Here is my config |
|
From: Thomas C. <tho...@al...> - 2008-04-21 19:57:19
|
Hi, I am running kvm-66 on top of a debian sid host with 2.6.24 (intel 32bit host). Got the following in my logs today : Apr 21 17:55:01 buffy kernel: WARNING: at /usr/src/modules/kvm/mmu.c:390 account_shadowed() Apr 21 17:55:01 buffy kernel: Pid: 21416, comm: kvm Tainted: P 2.6.24-1-686 #1 Apr 21 17:55:01 buffy kernel: [<f8d07a36>] kvm_mmu_get_page+0x42d/0x447 [kvm] Apr 21 17:55:01 buffy kernel: [<f8d08cca>] kvm_mmu_load+0xdf/0x15c [kvm] Apr 21 17:55:01 buffy kernel: [<f8affe41>] vmx_queue_exception+0x0/0x33 [kvm_intel] Apr 21 17:55:01 buffy kernel: [<f8d05521>] kvm_arch_vcpu_ioctl_run+0x233/0x5a9 [kvm] Apr 21 17:55:01 buffy kernel: [<f8d013aa>] kvm_vcpu_ioctl+0xe4/0x34c [kvm] Apr 21 17:55:01 buffy kernel: [<c0159078>] delayacct_end+0x70/0x77 Apr 21 17:55:01 buffy kernel: [<c015aa19>] sync_page+0x0/0x3b Apr 21 17:55:01 buffy kernel: [<c0159388>] __delayacct_blkio_end+0x5b/0x5f Apr 21 17:55:01 buffy kernel: [<c02bcaab>] io_schedule+0x64/0x80 Apr 21 17:55:01 buffy kernel: [<c011e07d>] enqueue_entity+0x2b/0x3d Apr 21 17:55:01 buffy kernel: [<c0115343>] apic_wait_icr_idle+0xe/0x15 Apr 21 17:55:01 buffy kernel: [<c011e0a5>] enqueue_task_fair+0x16/0x24 Apr 21 17:55:01 buffy kernel: [<c011d643>] enqueue_task+0x52/0x5d Apr 21 17:55:01 buffy kernel: [<c011de9e>] resched_task+0x52/0x54 Apr 21 17:55:01 buffy kernel: [<c011f459>] try_to_wake_up+0x2b8/0x2c2 Apr 21 17:55:01 buffy kernel: [<c011d47e>] __wake_up_common+0x32/0x5c Apr 21 17:55:01 buffy kernel: [<c011eecc>] __wake_up+0x32/0x42 Apr 21 17:55:01 buffy kernel: [<c013e25c>] wake_futex+0x3b/0x45 Apr 21 17:55:01 buffy kernel: [<c013e4de>] futex_wake+0x81/0xb0 Apr 21 17:55:01 buffy kernel: [<c013f097>] do_futex+0x77/0x983 Apr 21 17:55:01 buffy kernel: [<c011d9ca>] update_curr+0x62/0xef Apr 21 17:55:01 buffy kernel: [<c0103044>] __switch_to+0x9d/0x11d Apr 21 17:55:01 buffy kernel: [<f8d012c6>] kvm_vcpu_ioctl+0x0/0x34c [kvm] Apr 21 17:55:01 buffy kernel: [<c018285b>] do_ioctl+0x1f/0x62 Apr 21 17:55:01 buffy kernel: [<c0182ad5>] vfs_ioctl+0x237/0x249 Apr 21 17:55:01 buffy kernel: [<c0182b2c>] sys_ioctl+0x45/0x5d Apr 21 17:55:01 buffy kernel: [<c0103e5e>] sysenter_past_esp+0x6b/0xa1 Regards, Thomas. |
|
From: Marcelo T. <mto...@re...> - 2008-04-21 18:42:13
|
On Mon, Apr 21, 2008 at 01:24:00PM -0500, Anthony Liguori wrote: > Marcelo Tosatti wrote: > >From: Alan Pevec <ap...@re...> > > > > > >>- add serial console, workaround for F9 livecd KVM guest dying with > >>standard console only. > >> VNC console will go blank but node will continue to boot > >> > > > >With only console=tty qemu-kvm dies when, AFAICT from udevdebug output, > >start_udev is processing console rules. > > > >Here is backtrace: > > > >Program received signal SIGSEGV, Segmentation fault. > > > >[Switching to Thread -1208993168 (LWP 16163)] > > > >0x0095337d in memmove () from /lib/libc.so.6 > > > >Missing separate debuginfos, use: debuginfo-install SDL.i386 alsa-lib.i386 > >glibc.i686 gnutls.i386 libgcrypt.i386 libgpg-error.i386 zlib.i386 > > > > The info that's needed is what the size of the vnc frame buffer is. My > suspicion is that we're racing. A VCPU IO operation will trigger the > bit blit which will cause this vnc_copy path to hit. However, the VNC > server is not thread safe so if the IO thread is running simultaneously, > very bad things could happen. > > Is this with standard KVM or your lock break-up patches? Standard KVM. |
|
From: Anthony L. <an...@co...> - 2008-04-21 18:23:59
|
Marcelo Tosatti wrote: > From: Alan Pevec <ap...@re...> > > >> - add serial console, workaround for F9 livecd KVM guest dying with >> standard console only. >> VNC console will go blank but node will continue to boot >> > > With only console=tty qemu-kvm dies when, AFAICT from udevdebug output, start_udev is processing console rules. > > Here is backtrace: > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread -1208993168 (LWP 16163)] > > 0x0095337d in memmove () from /lib/libc.so.6 > > Missing separate debuginfos, use: debuginfo-install SDL.i386 alsa-lib.i386 glibc.i686 gnutls.i386 libgcrypt.i386 libgpg-error.i386 zlib.i386 > The info that's needed is what the size of the vnc frame buffer is. My suspicion is that we're racing. A VCPU IO operation will trigger the bit blit which will cause this vnc_copy path to hit. However, the VNC server is not thread safe so if the IO thread is running simultaneously, very bad things could happen. Is this with standard KVM or your lock break-up patches? Regards, Anthony Liguori |
|
From: Marcelo T. <mto...@re...> - 2008-04-21 18:16:28
|
From: Alan Pevec <ap...@re...>
> - add serial console, workaround for F9 livecd KVM guest dying with
> standard console only.
> VNC console will go blank but node will continue to boot
With only console=tty qemu-kvm dies when, AFAICT from udevdebug output, start_udev is processing console rules.
Here is backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208993168 (LWP 16163)]
0x0095337d in memmove () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install SDL.i386 alsa-lib.i386 glibc.i686 gnutls.i386 libgcrypt.i386 libgpg-error.i386 zlib.i386
(gdb) bt
#0 0x0095337d in memmove () from /lib/libc.so.6
#1 0x080b38ae in vnc_copy (ds=0x8181060, src_x=64, src_y=416, dst_x=64,
dst_y=400, w=72, h=16) at vnc.c:465
#2 0x080947ec in cirrus_bitblt_start (s=0xa2181e0)
at /usr/src/debug/kvm-60/qemu/hw/cirrus_vga.c:760
#3 0x08095008 in cirrus_hook_write_gr (s=0xa2181e0, reg_index=2534224968,
reg_value=2) at /usr/src/debug/kvm-60/qemu/hw/cirrus_vga.c:1064
#4 0x08095bb9 in vga_ioport_write (opaque=0xa2181e0, addr=975, val=2)
at /usr/src/debug/kvm-60/qemu/hw/cirrus_vga.c:2958
#5 0x080d3277 in kvm_outw (opaque=0x0, addr=3072, data=<value optimized out>)
at /usr/src/debug/kvm-60/qemu/qemu-kvm.c:478
#6 0x0814b643 in kvm_run (kvm=0xa0de028, vcpu=0) at libkvm.c:719
#7 0x080d2bf2 in kvm_cpu_exec (env=0xa1085e0)
at /usr/src/debug/kvm-60/qemu/qemu-kvm.c:143
#8 0x080d36d2 in kvm_main_loop_cpu (env=0xa1085e0)
at /usr/src/debug/kvm-60/qemu/qemu-kvm.c:343
#9 0x08057cf8 in main (argc=20, argv=0xbfc42914)
at /usr/src/debug/kvm-60/qemu/vl.c:7817
#10 0x008f8390 in __libc_start_main () from /lib/libc.so.6
#11 0x0804ce21 in _start ()
VNC server bug? Can QEMU/KVM experts have a look? Any other hints?
My host is F8, kernel-2.6.24.4-64.fc8 kvm-60-3.fc8 libvirt-0.4.1-3.fc8.
Thanks!
|
|
From: David S. A. <da...@ci...> - 2008-04-21 17:07:37
|
host:
2.6.25-rc8, x86_64, kvm-66
1 dual-core Xeon(R) CPU 3050 @ 2.13GHz
6 GB RAM
(This behavior also occurs on a larger server with 2 dual-core Xeon(R) CPU
5140 @ 2.33GHz, 4 GB RAM. Same kernel and kvm versions.)
guest:
RHEL3 U8 (2.4.21-47.ELsmp), 2 vcpus, 2 GB RAM
As usual, waited for a guest "event" -- high system time in guest which appears
to lock it up. Following the event, kscand was the top CPU user (cumulative
time) in the guest.
During the event, 2 qemu threads are pegging the host CPU at 100%. Top samples
from oprofile (oprofile was started after the freeze start and stopped when
guest response returned):
samples % image name app name symbol name
171716 35.1350 kvm-intel.ko kvm_intel vmx_vcpu_run
45836 9.3786 vmlinux vmlinux copy_user_generic_string
39417 8.0652 kvm.ko kvm kvm_read_guest_atomic
23604 4.8296 vmlinux vmlinux add_preempt_count
22878 4.6811 vmlinux vmlinux __smp_call_function_mask
16143 3.3030 kvm.ko kvm gfn_to_hva
14648 2.9971 vmlinux vmlinux sub_preempt_count
14589 2.9851 kvm.ko kvm __gfn_to_memslot
11666 2.3870 kvm.ko kvm unalias_gfn
10834 2.2168 kvm.ko kvm kvm_mmu_zap_page
10532 2.1550 kvm.ko kvm paging64_prefetch_page
6285 1.2860 kvm-intel.ko kvm_intel handle_exception
6066 1.2412 kvm.ko kvm kvm_arch_vcpu_ioctl_run
4741 0.9701 kvm.ko kvm kvm_add_trace
3801 0.7777 vmlinux vmlinux __copy_from_user_inatomic
3592 0.7350 vmlinux vmlinux follow_page
3326 0.6805 kvm.ko kvm mmu_memory_cache_alloc
3317 0.6787 kvm-intel.ko kvm_intel kvm_handle_exit
2971 0.6079 kvm.ko kvm paging64_page_fault
2777 0.5682 kvm.ko kvm paging64_walk_addr
2294 0.4694 kvm.ko kvm kvm_mmu_pte_write
2278 0.4661 kvm.ko kvm kvm_flush_remote_tlbs
2266 0.4636 kvm-intel.ko kvm_intel vmcs_writel
2086 0.4268 kvm.ko kvm mmu_set_spte
2041 0.4176 kvm.ko kvm kvm_read_guest
1615 0.3304 vmlinux vmlinux free_hot_cold_page
david
Avi Kivity wrote:
> David S. Ahern wrote:
>> I added the traces and captured data over another apparent lockup of
>> the guest.
>> This seems to be representative of the sequence (pid/vcpu removed).
>>
>> (+4776) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>> c016127c ]
>> (+ 0) PAGE_FAULT [ errorcode = 0x00000003, virt = 0x00000000
>> c0009db4 ]
>> (+3632) VMENTRY
>> (+4552) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>> c016104a ]
>> (+ 0) PAGE_FAULT [ errorcode = 0x0000000b, virt = 0x00000000
>> fffb61c8 ]
>> (+ 54928) VMENTRY
>>
>
> Can you oprofile the host to see where the 54K cycles are spent?
>
>> (+4568) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>> c01610e7 ]
>> (+ 0) PAGE_FAULT [ errorcode = 0x00000003, virt = 0x00000000
>> c0009db4 ]
>> (+ 0) PTE_WRITE [ gpa = 0x00000000 00009db4 gpte = 0x00000000
>> 41c5d363 ]
>> (+8432) VMENTRY
>> (+3936) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>> c01610ee ]
>> (+ 0) PAGE_FAULT [ errorcode = 0x00000003, virt = 0x00000000
>> c0009db0 ]
>> (+ 0) PTE_WRITE [ gpa = 0x00000000 00009db0 gpte = 0x00000000
>> 00000000 ]
>> (+ 13832) VMENTRY
>>
>>
>> (+5768) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>> c016127c ]
>> (+ 0) PAGE_FAULT [ errorcode = 0x00000003, virt = 0x00000000
>> c0009db4 ]
>> (+3712) VMENTRY
>> (+4576) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>> c016104a ]
>> (+ 0) PAGE_FAULT [ errorcode = 0x0000000b, virt = 0x00000000
>> fffb61d0 ]
>> (+ 0) PTE_WRITE [ gpa = 0x00000000 3d5981d0 gpte = 0x00000000
>> 3d55d047 ]
>>
>
> This indeed has the accessed bit clear.
>
>> (+ 65216) VMENTRY
>> (+4232) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>> c01610e7 ]
>> (+ 0) PAGE_FAULT [ errorcode = 0x00000003, virt = 0x00000000
>> c0009db4 ]
>> (+ 0) PTE_WRITE [ gpa = 0x00000000 00009db4 gpte = 0x00000000
>> 3d598363 ]
>>
>
> This has the accessed bit set and the user bit clear, and the pte
> pointing at the previous pte_write gpa. Looks like a kmap_atomic().
>
>> (+8640) VMENTRY
>> (+3936) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>> c01610ee ]
>> (+ 0) PAGE_FAULT [ errorcode = 0x00000003, virt = 0x00000000
>> c0009db0 ]
>> (+ 0) PTE_WRITE [ gpa = 0x00000000 00009db0 gpte = 0x00000000
>> 00000000 ]
>> (+ 14160) VMENTRY
>>
>> I can forward a more complete time snippet if you'd like. vcpu0 +
>> corresponding
>> vcpu1 files have 85000 total lines and compressed the files total ~500k.
>>
>> I did not see the FLOODED trace come out during this sample though I
>> did bump
>> the count from 3 to 4 as you suggested.
>>
>>
>>
>
> Bumping the count was supposed to remove the flooding...
>
>> Correlating rip addresses to the 2.4 kernel:
>>
>> c0160d00-c0161290 = page_referenced
>>
>> It looks like the event is kscand running through the pages. I
>> suspected this
>> some time ago, and tried tweaking the kscand_work_percent sysctl
>> variable. It
>> appeared to lower the peak of the spikes, but maybe I imagined it. I
>> believe
>> lowering that value makes kscand wake up more often but do less work
>> (page
>> scanning) each time it is awakened.
>>
>>
>
> What does 'top' in the guest show (perhaps sorted by total cpu time
> rather than instantaneous usage)?
>
> What host kernel are you running? How many host cpus?
>
|
|
From: Damjan <gd...@ma...> - 2008-04-21 15:59:55
|
> > If I try > > $ qemu -kernel minimal-kernel -drive file=jeos-devel.img,if=virtio > > I get the following error: > > A disk image must be given for 'hda' when booting a Linux kernel > > is this neccesseary? > Hi, i don't know if it is always needed (I saw some patches to avoid > that) but you can use: > > qemu -kernel minimal-kernel -drive file=jeos-devel.img,if=virtio -hda /dev/zero cool that works, thanks -- damjan | дамјан This is my jabber ID --> da...@ba... -- not my mail address, it's a Jabber ID --^ :) |
|
From: Jes S. <je...@sg...> - 2008-04-21 15:35:18
|
Hi, This one fixes a segfault problem I am seeing on ia64 due to the malloc'ed address being truncated to 32 bit. Cheers, Jes |
|
From: Soren H. <so...@ub...> - 2008-04-21 15:20:43
|
On Mon, Apr 21, 2008 at 08:51:17AM -0500, Anthony Liguori wrote:
>> We're releasing on Thursday, and I needed a quick fix, so I reverted
>> the calls to kvm_{save,load}_registers in vmport_ioport_read to the
>> old code that simply saved the eax, ebx, ecx, edx, esi, and edi
>> registers, but I'm supposing kvm_{load,save}_registers really should
>> work here.
/me sighs very deeply
Ok, first chance I get, I'm signing up for "Patch management 101". :( I
got some tests mixed around, so it failing is actually dependent on
whether EIP (not LSTAR as I originally thought) is restored or not.
I have a patch that fixes it, but I need to work a few things out first
before I submit it.
> Ah, you may have missed the fix that updated the KVM load/save
> functions to deal with the in-kernel APIC.
Indeed.
> It turns out, vmmouse was horribly broken with SMP guests too. See
>
> commit 9949bd84ac4dfdfc60b2974557819637b8719911
> Author: Anthony Liguori <ali...@us...>
> Date: Thu Apr 3 18:37:16 2008 -0500
>
> commit 5208ce19dca268f84a2b9441c2fbb6129161e44c
> Author: Marcelo Tosatti <mto...@re...>
> Date: Thu Apr 3 20:24:37 2008 -0300
I did my tests using kvm-65 userland and kernel, so these two should
already be included, afaics.
> commit 85a67aa2a1b942ddccfcbd625d280869367edc95
> Author: Marcelo Tosatti <mto...@re...>
> Date: Fri Apr 11 13:24:41 2008 -0300
This did not change anything for me.
--
Soren Hansen |
Virtualisation specialist | Ubuntu Server Team
Canonical Ltd. | http://www.ubuntu.com/
|
|
From: Guillaume T. <gui...@ex...> - 2008-04-21 15:11:45
|
On Fri, 18 Apr 2008 10:25:15 -0500
Anthony Liguori <an...@co...> wrote:
> I'd prefer you not do an emulate_instruction loop at all. Just emulate
> one instruction on vmentry failure and let VT tell you what instructions
> you need to emulate.
>
> It's only four instructions so I don't think the performance is going to
> matter. Take a look at the patch I posted previously.
you were right, I not updated eip correctly. It is fixed now with the
following code:
case 0xea: /* jmp (far, absolute) */ {
struct kvm_segment kvm_seg;
uint16_t eip;
uint16_t sel;
int ret;
eip = insn_fetch(u16, 2, c->eip);
sel = insn_fetch(u16, 2, c->eip);
kvm_x86_ops->get_segment(ctxt->vcpu, &kvm_seg, VCPU_SREG_CS);
kvm_seg.selector = sel;
ret = load_segment_descriptor(ctxt->vcpu, kvm_seg.selector, 9,
VCPU_SREG_CS);
if (ret < 0 ) {
printk(KERN_INFO "%s: Failed to load CS selector\n",
__FUNCTION__);
goto cannot_emulate;
}
c->eip = eip;
break;
I print the instruction to be emulated and it seems ok. I have the following outputs:
[24203.663324] vmentry_failure: emulation at (46e53) rip 6e13: ea 18 6e 18
[24203.664668] vmentry_failure: emulation at (46e58) rip 6e18: 66 b8 20 00
[24203.668650] vmentry_failure: emulation failed (vmentry failure) rip 6e18 66 b8 20 00
So the emulation that failed is "mov $0x20, %ax". It needs to be
emulated. As you said Anthony it's only four instructions that need to
be emulated, shouldn't be a big issue.
Best regards,
Guillaume
|
|
From: Damjan <gd...@ma...> - 2008-04-21 14:41:51
|
I have some questions for the FAQ, about the configuration of Linux guests: a) is swap needed in the guest (I'd say no, but..) b) what filesystem is best for a guest c) what io scheduler in the guest (noop? or cfq) d) are there any runtime kernel tweaks for the guest (/proc/sys)? e) suggested linux kernel source configuration (.config)? -- damjan | дамјан This is my jabber ID --> da...@ba... -- not my mail address, it's a Jabber ID --^ :) |
|
From: Damjan <gd...@ma...> - 2008-04-21 14:30:13
|
If I try $ qemu -kernel minimal-kernel -drive file=jeos-devel.img,if=virtio I get the following error: A disk image must be given for 'hda' when booting a Linux kernel is this neccesseary? -- damjan | дамјан This is my jabber ID --> da...@ba... -- not my mail address, it's a Jabber ID --^ :) |
|
From: Gerd H. <kr...@re...> - 2008-04-21 14:20:15
|
Jeremy Fitzhardinge wrote: > Gerd Hoffmann wrote: >> Not really. There are only two calls, one in clocksource_read() and one >> in the init path. The later is superfluous I think because >> clocksource_read() is the only user of the shadowed time info. > > Hm. It doesn't look like shadow_time needs to be a static percpu at > all. It could just be a local to clocksource_read, I think. Good point, one more cleanup. thanks, Gerd -- http://kraxel.fedorapeople.org/xenner/ |
|
From: nathalie <ulo...@ME...> - 2008-04-21 14:15:30
|
Be permanently bigger and stronger, stop being the weakling you are today. http://www.yunabhel.com/ |
|
From: Anthony L. <an...@co...> - 2008-04-21 13:51:17
|
Soren Hansen wrote: > Esteemed kvm developers! > > I've been trying to debug this bug > > https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/219165 > > It originally revealed itself by failing to run grub (which is a 32 bit > binary) when installing Ubuntu from our live cd. It turned out to be a > more general problem of 32 bit binaries failing to run. The server > install worked like a charm. I eventually discovered that loading the > vmmouse driver triggered it and narrowed it down to the call to > kvm_load_registers in vmport_ioport_read. > > We're releasing on Thursday, and I needed a quick fix, so I reverted the > calls to kvm_{save,load}_registers in vmport_ioport_read to the old code > that simply saved the eax, ebx, ecx, edx, esi, and edi registers, but > I'm supposing kvm_{load,save}_registers really should work here. > Ah, you may have missed the fix that updated the KVM load/save functions to deal with the in-kernel APIC. It turns out, vmmouse was horribly broken with SMP guests too. See commit 9949bd84ac4dfdfc60b2974557819637b8719911 Author: Anthony Liguori <ali...@us...> Date: Thu Apr 3 18:37:16 2008 -0500 commit 5208ce19dca268f84a2b9441c2fbb6129161e44c Author: Marcelo Tosatti <mto...@re...> Date: Thu Apr 3 20:24:37 2008 -0300 commit 85a67aa2a1b942ddccfcbd625d280869367edc95 Author: Marcelo Tosatti <mto...@re...> Date: Fri Apr 11 13:24:41 2008 -0300 Regards, Anthony LIguori > I dug a bit further into the code and tried disabling various pieces of > the kvm_load_registers until it finally worked again. The problem seems > to only arise when the lstar msr is loaded. I've looked at the code, but > seeing as three days ago I didn't know there was such a thing as an > lstar msr, I'm finding myself getting stuck. :) > > Any pointers in the right direction would be lovely. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ------------------------------------------------------------------------ > > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel > |
|
From: Jeremy F. <je...@go...> - 2008-04-21 13:38:35
|
Gerd Hoffmann wrote:
> +cycle_t pvclock_clocksource_read(struct kvm_vcpu_time_info *src)
> +{
> + struct pvclock_shadow_time *shadow;
> + cycle_t ret;
> + unsigned version;
> +
> + shadow = &get_cpu_var(shadow_time);
> + do {
> + version = pvclock_get_time_values(shadow, src);
> + barrier();
> + ret = shadow->system_timestamp + pvclock_get_nsec_offset(shadow);
> + barrier();
>
Is barrier() strong enough? Does kvm guarantee that the per-cpu time
parameters are only ever updated by that cpu? I'm pretty sure Xen does,
so that's OK.
J
|
|
From: Jeremy F. <je...@go...> - 2008-04-21 13:34:42
|
Gerd Hoffmann wrote:
> Jeremy Fitzhardinge wrote:
>
>> Xen could change the parameters in the instant after get_time_values().
>> That change could be as a result of suspend-resume, so the parameters
>> and the tsc could be wildly different.
>>
>
> Ah, ok, forgot the rdtsc in the picture. With that in mind I fully
> agree that the loop is needed. I think kvm guests can even hit that one
> with the vcpu migrating to a different physical cpu, so we better handle
> it correctly ;)
>
Yes, same with Xen.
>> Sure, but get_time_values() has several other callers.
>>
>
> Not really. There are only two calls, one in clocksource_read() and one
> in the init path. The later is superfluous I think because
> clocksource_read() is the only user of the shadowed time info.
>
Hm. It doesn't look like shadow_time needs to be a static percpu at
all. It could just be a local to clocksource_read, I think.
J
|
157 messages has been excluded from this view by a project administrator.
