Re: [patch 4/4] KVM-trace port to tracepoints
On Tue, 2008-07-22 at 21:46 +0300, Avi Kivity wrote: Jan Kiszka wrote: That's true - as long as you don't have to add/remove/modify tracepoints. I had to do this job in the past (not for KVM). Having 1 spot in 1 file (based on generic probes) would be handier in that case than 5 spots in 3 files. But if the KVM tracepoints are considered stable in their number and structure, that shouldn't be an issue here. Tracepoints aren't stable; they are artefacts of the implementation. Which IMHO makes it unsuitable for trace_mark() as that will be exported to user-space, and every time you change your tracepoints you'll change user visible things - not nice. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/4] KVM-trace port to tracepoints
Peter Zijlstra wrote: On Tue, 2008-07-22 at 21:46 +0300, Avi Kivity wrote: Jan Kiszka wrote: That's true - as long as you don't have to add/remove/modify tracepoints. I had to do this job in the past (not for KVM). Having 1 spot in 1 file (based on generic probes) would be handier in that case than 5 spots in 3 files. But if the KVM tracepoints are considered stable in their number and structure, that shouldn't be an issue here. Tracepoints aren't stable; they are artefacts of the implementation. Which IMHO makes it unsuitable for trace_mark() as that will be exported to user-space, and every time you change your tracepoints you'll change user visible things - not nice. They are used for debugging (mostly performance related), so changes are expected. What uses of trace_mark() depend on a stable interface? blktrace? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2025527 ] kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access
Bugs item #2025527, was opened at 2008-07-23 16:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025527group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access Initial Comment: This seems to be happening regularly with kvm-71 so I have downgraded to kvm-70. So far so good... I'm running Ubuntu 8.04.1 desktop amd64 2.6.24-19-generic #1 SMP. [84184.614760] Unable to handle kernel paging request at 00100100 RIP: [84184.614765] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614784] PGD 3b98d067 PUD 5da31067 PMD 0 [84184.614788] Oops: [1] SMP [84184.614790] CPU 2 [84184.614792] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm binfmt_misc rfcomm l2cap bluetooth ppdev acpi_cpufreq cpufreq_userspace cpufreq_ondemand cpufreq_stats cpufreq_conservative freq_table cpufreq_powersave dock video output container sbs sbshc battery ipv6 xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp ac xt_state lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi nvidia(P) usb_storage snd_seq_midi_event libusual sky2 i2c_core iTCO_wdt snd_seq iTCO_vendor_support snd_timer snd_seq_device parport_pc snd parport shpchp evdev pcspkr intel_agp pci_hotplug button soundcore iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables x_tables usbhid hid ext3 jbd mbcache sg sr_mod sd_mod cdrom pata_acpi ehci_hcd uhci_hcd ata_piix ata_generic libata scsi_mod usbcore thermal processor fan fbcon tileblit font bitblit softcursor fuse [84184.614855] Pid: 6868, comm: qemu Tainted: P2.6.24-19-generic #1 [84184.614857] RIP: 0010:[88c67545] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614867] RSP: 0018:81003bbefe20 EFLAGS: 00010246 [84184.614869] RAX: RBX: 81001addc000 RCX: [84184.614871] RDX: 00100100 RSI: 0005 RDI: 81001addeaf0 [84184.614873] RBP: 81003bbefe88 R08: ec8fdb30 R09: 00100100 [84184.614875] R10: R11: 0001 R12: [84184.614877] R13: 81001addc020 R14: 4010ae42 R15: [84184.614879] FS: 7f80e48e56e0() GS:81007dc01a00() knlGS: [84184.614882] CS: 0010 DS: ES: CR0: 8005003b [84184.614884] CR2: 00100100 CR3: 3bad3000 CR4: 26e0 [84184.614885] DR0: DR1: DR2: [84184.614888] DR3: DR6: 0ff0 DR7: 0400 [84184.614890] Process qemu (pid: 6868, threadinfo 81003bbee000, task 81005d910fc0) [84184.614892] Stack: 88c630f2 000e 0001fffe 0001 [84184.614897] 81001addc000 81003bbefe88 4010ae42 0005 [84184.614900] 88c60771 810001022598 8062b540 0082 [84184.614904] Call Trace: [84184.614912] [88c630f2] :kvm:kvm_vm_ioctl_get_dirty_log+0x82/0xc0 [84184.614926] [88c60771] :kvm:kvm_vm_ioctl+0xd1/0x200 [84184.614934] [80256e0e] hrtimer_start+0xee/0x170 [84184.614941] [80233e20] default_wake_function+0x0/0x10 [84184.614948] [802c070f] do_ioctl+0x2f/0xa0 [84184.614953] [802c09a0] vfs_ioctl+0x220/0x2c0 [84184.614957] [802b32fd] vfs_read+0xed/0x190 [84184.614963] [802c0ad1] sys_ioctl+0x91/0xb0 [84184.614971] [8020c37e] system_call+0x7e/0x83 [84184.614981] [84184.614982] [84184.614982] Code: 49 8b 11 49 39 f9 0f 18 0a 75 b9 f3 c3 66 66 66 66 66 2e 0f [84184.614991] RIP [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.615000] RSP 81003bbefe20 [84184.615002] CR2: 00100100 [84184.615005] ---[ end trace dbc91eb222360215 ]--- -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025527group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2025527 ] kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access
Bugs item #2025527, was opened at 2008-07-23 16:39 Message generated for change (Settings changed) made by danv You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025527group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access Initial Comment: This seems to be happening regularly with kvm-71 so I have downgraded to kvm-70. So far so good... I'm running Ubuntu 8.04.1 desktop amd64 2.6.24-19-generic #1 SMP. [84184.614760] Unable to handle kernel paging request at 00100100 RIP: [84184.614765] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614784] PGD 3b98d067 PUD 5da31067 PMD 0 [84184.614788] Oops: [1] SMP [84184.614790] CPU 2 [84184.614792] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm binfmt_misc rfcomm l2cap bluetooth ppdev acpi_cpufreq cpufreq_userspace cpufreq_ondemand cpufreq_stats cpufreq_conservative freq_table cpufreq_powersave dock video output container sbs sbshc battery ipv6 xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp ac xt_state lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi nvidia(P) usb_storage snd_seq_midi_event libusual sky2 i2c_core iTCO_wdt snd_seq iTCO_vendor_support snd_timer snd_seq_device parport_pc snd parport shpchp evdev pcspkr intel_agp pci_hotplug button soundcore iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables x_tables usbhid hid ext3 jbd mbcache sg sr_mod sd_mod cdrom pata_acpi ehci_hcd uhci_hcd ata_piix ata_generic libata scsi_mod usbcore thermal processor fan fbcon tileblit font bitblit softcursor fuse [84184.614855] Pid: 6868, comm: qemu Tainted: P2.6.24-19-generic #1 [84184.614857] RIP: 0010:[88c67545] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614867] RSP: 0018:81003bbefe20 EFLAGS: 00010246 [84184.614869] RAX: RBX: 81001addc000 RCX: [84184.614871] RDX: 00100100 RSI: 0005 RDI: 81001addeaf0 [84184.614873] RBP: 81003bbefe88 R08: ec8fdb30 R09: 00100100 [84184.614875] R10: R11: 0001 R12: [84184.614877] R13: 81001addc020 R14: 4010ae42 R15: [84184.614879] FS: 7f80e48e56e0() GS:81007dc01a00() knlGS: [84184.614882] CS: 0010 DS: ES: CR0: 8005003b [84184.614884] CR2: 00100100 CR3: 3bad3000 CR4: 26e0 [84184.614885] DR0: DR1: DR2: [84184.614888] DR3: DR6: 0ff0 DR7: 0400 [84184.614890] Process qemu (pid: 6868, threadinfo 81003bbee000, task 81005d910fc0) [84184.614892] Stack: 88c630f2 000e 0001fffe 0001 [84184.614897] 81001addc000 81003bbefe88 4010ae42 0005 [84184.614900] 88c60771 810001022598 8062b540 0082 [84184.614904] Call Trace: [84184.614912] [88c630f2] :kvm:kvm_vm_ioctl_get_dirty_log+0x82/0xc0 [84184.614926] [88c60771] :kvm:kvm_vm_ioctl+0xd1/0x200 [84184.614934] [80256e0e] hrtimer_start+0xee/0x170 [84184.614941] [80233e20] default_wake_function+0x0/0x10 [84184.614948] [802c070f] do_ioctl+0x2f/0xa0 [84184.614953] [802c09a0] vfs_ioctl+0x220/0x2c0 [84184.614957] [802b32fd] vfs_read+0xed/0x190 [84184.614963] [802c0ad1] sys_ioctl+0x91/0xb0 [84184.614971] [8020c37e] system_call+0x7e/0x83 [84184.614981] [84184.614982] [84184.614982] Code: 49 8b 11 49 39 f9 0f 18 0a 75 b9 f3 c3 66 66 66 66 66 2e 0f [84184.614991] RIP [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.615000] RSP 81003bbefe20 [84184.615002] CR2: 00100100 [84184.615005] ---[ end trace dbc91eb222360215 ]--- -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025527group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2025534 ] gettimeofday goes backward
Bugs item #2025534, was opened at 2008-07-23 10:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025534group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rafal Wijata (ravpl) Assigned to: Nobody/Anonymous (nobody) Summary: gettimeofday goes backward Initial Comment: kvm version: 71 host: rhel51 2.6.18-92.1.6.el5 64bit 16G RAM, 8CPU guest: rhel51 2.6.18-92.1.6.el5 64bit, 3.5G ram, 2 CPU guest run as: qemu-system-x86_64 $DEVICES -m $MEM -smp $CPUS -net nic,macaddr=$MAC,model=e1000 -net tap,script=./ifup -nographic -daemonize in the guest executed two consecutive gettimeofday (boost::ptime in fact), the latter returned time smaller than first (2008-Jul-22 16:34:15.477000, 2008-Jul-22 16:34:15.47) I'm sure no time change was made(like rdate or ntpdate) on neither host or guest. No time-releated options were passed to kernel(host or guest) Any workaround? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025534group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2017966 ] Booting Vista Guest may crash host
Bugs item #2017966, was opened at 2008-07-14 06:30 Message generated for change (Comment added) made by jiajun You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: Booting Vista Guest may crash host Initial Comment: Booting Vista Guest may cause host hang on latest commit. kvm.git a10cfebe86cf85a1d2ab02fccbc1e8c2b3eb92b5 and userspace.git fbd8c32b77751236b35397e05c0bc84c48833d97. The issue does not happen every time, but booting Vista Guest for more than 10 times can reproduce the bug. Serial output is attached. -- Comment By: Jiajun Xu (jiajun) Date: 2008-07-23 01:45 Message: Logged In: YES user_id=2142959 Originator: YES I verified on latest commit kvm.git aa2ed2c1b5f020beace44ab7745d290d64cd6c89. The issue does not appear now. -- Comment By: Marcelo Tosatti (mtosatti) Date: 2008-07-22 13:42 Message: Logged In: YES user_id=2022487 Originator: NO Jiajun, Can you try to reproduce that with current git as of today? I was experiencing all sorts of host crashes this week, but since ea8b7f0542e0420240d057f7954808c65c4d13fc its back to normal. Tested approx. 1h of continuous reboot on Vista 32 Business without problems. -- Comment By: Jiajun Xu (jiajun) Date: 2008-07-14 07:08 Message: Logged In: YES user_id=2142959 Originator: YES It's Vista x86. -- Comment By: Avi Kivity (avik) Date: 2008-07-14 06:59 Message: Logged In: YES user_id=539971 Originator: NO Is this Vista x86 or Vista x64? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/4] KVM-trace port to tracepoints
On Wed, 2008-07-23 at 11:08 +0300, Avi Kivity wrote: Peter Zijlstra wrote: On Tue, 2008-07-22 at 21:46 +0300, Avi Kivity wrote: Jan Kiszka wrote: That's true - as long as you don't have to add/remove/modify tracepoints. I had to do this job in the past (not for KVM). Having 1 spot in 1 file (based on generic probes) would be handier in that case than 5 spots in 3 files. But if the KVM tracepoints are considered stable in their number and structure, that shouldn't be an issue here. Tracepoints aren't stable; they are artefacts of the implementation. Which IMHO makes it unsuitable for trace_mark() as that will be exported to user-space, and every time you change your tracepoints you'll change user visible things - not nice. They are used for debugging (mostly performance related), so changes are expected. What uses of trace_mark() depend on a stable interface? blktrace? There are currently no trace_mark() sites in the kernel that I'm aware of (except for the scheduler :-/, and those should be converted to tracepoints ASAP). Andrew raised the whole point about trace_mark() generating an user-visible interface and thus it should be stable, and I agree with that. What that means is that trace_mark() can only be used for really stable points. This in turn means we might as well use trace points. Which allows for the conclusion that trace_mark() is not needed and could be removed from the kernel. However - it might be handy for ad-hoc debugging purposes that never see the light of day (linus' git tree in this case). So on those grounds one could argue against removing trace_mark. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/4] KVM-trace port to tracepoints
Peter Zijlstra wrote: There are currently no trace_mark() sites in the kernel that I'm aware of (except for the scheduler :-/, and those should be converted to tracepoints ASAP). Andrew raised the whole point about trace_mark() generating an user-visible interface and thus it should be stable, and I agree with that. What that means is that trace_mark() can only be used for really stable points. This in turn means we might as well use trace points. Which allows for the conclusion that trace_mark() is not needed and could be removed from the kernel. However - it might be handy for ad-hoc debugging purposes that never see the light of day (linus' git tree in this case). So on those grounds one could argue against removing trace_mark But trace_mark() is so wonderful. Can't we just declare the tracemarks as a non-stable interface? Perhaps add an unstable_trace_mark() to make it clear. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/4] KVM-trace port to tracepoints
Christoph Hellwig wrote: On Wed, Jul 23, 2008 at 10:55:03AM +0200, Peter Zijlstra wrote: Andrew raised the whole point about trace_mark() generating an user-visible interface and thus it should be stable, and I agree with that. I'm not sure why this comes up again and again, but it's utter bullshit. trace_mark does not generate any kind of user interface, just purely a kernel internal interface. trace_mark() is implement kvmtrace, which is propagated to userspace. So while trace_mark() itself is not a userspace interface, one of its users is. It's an unstable interface. But so is dmesg; that's the nature of tracing. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/4] KVM-trace port to tracepoints
On Wed, Jul 23, 2008 at 01:08:41PM +0300, Avi Kivity wrote: trace_mark() is implement kvmtrace, which is propagated to userspace. So while trace_mark() itself is not a userspace interface, one of its users is. It's an unstable interface. But so is dmesg; that's the nature of tracing. Trace_mark is as stable as any other kernel interface, and the data you pass through it is as stable as you want it to. In most cases like kvmtrace or my spu scheduler tracing code the trace data is directly forwarded through a userspace interface, and that is as stable as any freeform interface, e.g. as like printk mentioned above. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/4] KVM-trace port to tracepoints
* Peter Zijlstra ([EMAIL PROTECTED]) wrote:
On Wed, 2008-07-23 at 12:32 +0300, Avi Kivity wrote:
Peter Zijlstra wrote:
There are currently no trace_mark() sites in the kernel that I'm aware
of (except for the scheduler :-/, and those should be converted to
tracepoints ASAP).
Andrew raised the whole point about trace_mark() generating an
user-visible interface and thus it should be stable, and I agree with
that.
What that means is that trace_mark() can only be used for really stable
points.
This in turn means we might as well use trace points.
Which allows for the conclusion that trace_mark() is not needed and
could be removed from the kernel.
However - it might be handy for ad-hoc debugging purposes that never see
the light of day (linus' git tree in this case). So on those grounds one
could argue against removing trace_mark
But trace_mark() is so wonderful.
I guess tastes differ...
Can't we just declare the tracemarks
as a non-stable interface?
Perhaps add an unstable_trace_mark() to make it clear.
At the very least it would need its own output channel. But I'm afraid
this will be KS material.
Hi Peter,
Currently what I have in LTTng includes this output channel. It works
for me, but if I can make it work for others that would be great.
- Tracepoints in kernel code to instrument the kernel.
- LTTng probes connect on those relatively stable tracepoints. They
format the data so it's meaningful to userspace (e.g. extracts the pid
of the prev and next process at sched_switch).
- The LTTng serializer is connected on those markers. It parses the
format string to dynamically reserve space in the relay buffer, write
a timestamp and event ID (one event ID is pre-assigned to a marker
name) and copy the arguments from the stack to the event record (which
has a variable size).
Event IDs and timestamps are added by LTTng, thus not required by
markers. However, one can think of this flow as an efficient and compact
binary data export mechanism to userspace.
Headers exports data type sizes and endianness, a special data channel
exports the mappings between { marker name, ID, format string } so
events are self-described. Therefore, one can add any event he likes and
it will be automatically understood by the tracing toolchain.
If an event is removed or filtered out or modified (by changing its
field name), the userspace trace analyser will detect it and the
specific probe which expects this event will fail to load, leading to
missing analyses, but nothing more than that.
So currently what we would have is, more or less : trace_marks located
within LTTng are kept in sync with userland, but the whole chain also
allows to add debug-style trace_marks directly in the kernel code
(this is really useful when trying to perform a low-impact printk-like
runtime bissection of a bug in the kernel code.
I actually see the trace_marks/LTTng combination as a printk which would
extract information in its binary form instead of using text-formatting.
The actual formatting can then be done later, in userland, if ever
needed (many analyses use the raw binary format directly). I guess KS
would be a good opportunity to discuss this interface topic.
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/4] KVM-trace port to tracepoints
* Avi Kivity ([EMAIL PROTECTED]) wrote:
Peter Zijlstra wrote:
On Tue, 2008-07-22 at 21:46 +0300, Avi Kivity wrote:
Jan Kiszka wrote:
That's true - as long as you don't have to add/remove/modify
tracepoints. I had to do this job in the past (not for KVM). Having 1
spot in 1 file (based on generic probes) would be handier in that case
than 5 spots in 3 files. But if the KVM tracepoints are considered
stable in their number and structure, that shouldn't be an issue here.
Tracepoints aren't stable; they are artefacts of the implementation.
Which IMHO makes it unsuitable for trace_mark() as that will be exported
to user-space, and every time you change your tracepoints you'll change
user visible things - not nice.
They are used for debugging (mostly performance related), so changes are
expected.
What uses of trace_mark() depend on a stable interface? blktrace?
Actually, LTTng likes to have the { marker name, field name } pairs
unchanged for the markers it looks for, but that's about it. If a
userspace analysis plugin fails to see a marker (because it is disabled
or changed), it just does not apply its particular analysis on the
trace.
Since the markers and marker types are self-described in the trace,
userspace can detect any change the the present markers, so there is no
need to rely on version numbers because we are able to proceed to a
complete marker list verification (names, field names, types) before
starting the trace analysis.
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Paravirt loops per jiffy calculation
On Wed, Jul 23, 2008 at 7:07 AM, Gerd Hoffmann [EMAIL PROTECTED] wrote:
Hi,
Turns out that only implementing a pv get_tsc_khz is not enough, since
it will only do the right thing for cpu0, which is not what we desire.
So we set preset_lpj. Recall this code is run before arch parameter setup,
so if we pass lpj=xx in the command line, it'll still work.
Hmm, why kvm needs the preset_lpj thing and xen doesn't?
I asked myself the same question. But from the snippet in calibrate.c:
if (preset_lpj) {
loops_per_jiffy = preset_lpj;
printk(KERN_INFO
Calibrating delay loop (skipped) preset value.. );
} else if ((smp_processor_id() == 0) lpj_fine) {
loops_per_jiffy = lpj_fine;
printk(KERN_INFO
Calibrating delay loop (skipped),
value calculated using timer frequency.. );
} else if ((loops_per_jiffy = calibrate_delay_direct()) != 0) {
printk(KERN_INFO
Calibrating delay using timer specific routine.. );
The third one is the one we want to skip. The second one, runs only for CPU0.
calibrate_delay_loop() itself, is called very early from smp_callin,
and tsc calibration only sets lpj_fine. So I don't see too much of an
option here.
cheers,
Gerd
--
http://kraxel.fedorapeople.org/xenner/
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] KVM: PCIPT: fix interrupt handling
* On Wednesday 16 Jul 2008 18:47:01 Ben-Ami Yassour wrote:
This patch fixes a few problems with the interrupt handling for
passthrough devices.
1. Pass the interrupt handler the pointer to the device, so we do not
need to lock the pcipt lock in the interrupt handler.
2. Remove the pt_irq_handled bitmap - it is no longer needed.
3. Split kvm_pci_pt_work_fn into two functions, one for interrupt
injection and another for the ack - is much simpler code this way.
4. Change the passthrough initialization order - add the device
structure to the list, before registering the interrupt handler.
5. On passthrough destruction path, free the interrupt handler before
cleaning queued work.
Signed-off-by: Ben-Ami Yassour [EMAIL PROTECTED]
---
if (irqchip_in_kernel(kvm)) {
+ match-pt_dev.guest.irq = pci_pt_dev-guest.irq;
+ match-pt_dev.host.irq = dev-irq;
+ if (kvm-arch.vioapic)
+ kvm-arch.vioapic-ack_notifier = kvm_pci_pt_ack_irq;
+ if (kvm-arch.vpic)
+ kvm-arch.vpic-ack_notifier = kvm_pci_pt_ack_irq;
+
We shouldn't register this notifier unless we get the irq below to avoid
unneeded function calls and checks.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2017966 ] Booting Vista Guest may crash host
Bugs item #2017966, was opened at 2008-07-14 09:30 Message generated for change (Settings changed) made by mtosatti You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: Booting Vista Guest may crash host Initial Comment: Booting Vista Guest may cause host hang on latest commit. kvm.git a10cfebe86cf85a1d2ab02fccbc1e8c2b3eb92b5 and userspace.git fbd8c32b77751236b35397e05c0bc84c48833d97. The issue does not happen every time, but booting Vista Guest for more than 10 times can reproduce the bug. Serial output is attached. -- Comment By: Jiajun Xu (jiajun) Date: 2008-07-23 04:45 Message: Logged In: YES user_id=2142959 Originator: YES I verified on latest commit kvm.git aa2ed2c1b5f020beace44ab7745d290d64cd6c89. The issue does not appear now. -- Comment By: Marcelo Tosatti (mtosatti) Date: 2008-07-22 16:42 Message: Logged In: YES user_id=2022487 Originator: NO Jiajun, Can you try to reproduce that with current git as of today? I was experiencing all sorts of host crashes this week, but since ea8b7f0542e0420240d057f7954808c65c4d13fc its back to normal. Tested approx. 1h of continuous reboot on Vista 32 Business without problems. -- Comment By: Jiajun Xu (jiajun) Date: 2008-07-14 10:08 Message: Logged In: YES user_id=2142959 Originator: YES It's Vista x86. -- Comment By: Avi Kivity (avik) Date: 2008-07-14 09:59 Message: Logged In: YES user_id=539971 Originator: NO Is this Vista x86 or Vista x64? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
scsi broken 4GB RAM
I do not know if this is a bug in qemu or the linux kernel sym53c8xx module (I haven't had the opportunity to test with anything other than Linux at the moment) but if one starts an qemu instance with -m 4096 and larger the scsi emulated disk fails in the Linux guest. If booting any install cd the /dev/sda is seen as only 512B in size and if booting an ubuntu 8.04-amd64 with the secondary drive as scsi it is seen with the correct size but one cannot read not write the partition table. Is there anyone out there that could test say a Windows image on scsi with 4GB or more of RAM and see if it works or not? If so it could be the linux driver that is faulty. /Henrik Holst -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2026321 ] -smp 2 has no effect and reduces stability
Bugs item #2026321, was opened at 2008-07-24 10:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2026321group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: -smp 2 has no effect and reduces stability Initial Comment: CPU: Intel Core 2 Quad Q6600 Dist: Ubuntu 8.04.1 amd64 desktop Kernel: 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux Running KVM-70 or KVM-71 with -smp 2 seems to have no effect on the guest (tested both RHEL 4.0 and WinXP guests). The guest fails to see more than one CPU, and typing info cpus in the monitor makes KVM crash instantly (though if you're quick you can see it output info about 2 VCPUs before crashing). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2026321group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2026321 ] -smp 2 has no effect and reduces stability
Bugs item #2026321, was opened at 2008-07-23 21:32 Message generated for change (Comment added) made by iggy_cav You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2026321group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: -smp 2 has no effect and reduces stability Initial Comment: CPU: Intel Core 2 Quad Q6600 Dist: Ubuntu 8.04.1 amd64 desktop Kernel: 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux Running KVM-70 or KVM-71 with -smp 2 seems to have no effect on the guest (tested both RHEL 4.0 and WinXP guests). The guest fails to see more than one CPU, and typing info cpus in the monitor makes KVM crash instantly (though if you're quick you can see it output info about 2 VCPUs before crashing). -- Comment By: Brian Jackson (iggy_cav) Date: 2008-07-23 22:03 Message: Logged In: YES user_id=611130 Originator: NO I don't know about RHEL 4, but if you installed XP without -smp 1 then it installs a uniprocessor HAL, which will never see more than one cpu. I also tried info cpus and it worked fine. I'm running kvm.git from 20080720 (tagged kvm-72rc1). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2026321group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Simple way of putting a VM on a LAN
Javier Guerra wrote: On Wed, Jul 9, 2008 at 11:28 AM, Bill Davidsen [EMAIL PROTECTED] wrote: A bit of the original problem seems to have been clipped before you read it, or I stated it poorly. i think you're very confused. maybe you got it working the hard way, but it's really simple to do the easy way. Your easy way seems to mean using Debian, other distributions don't have some of the scripts, or they are in different places or do different things. Other thoughts below. first, you have to do some small preparations on the host machine, but nothing difficult. this is what i do on my workstation (kubuntu) so that i can fire up a test VM at any moment's whim: - setup a bridge, and use it as main interface - add a /etc/qemu-ifup script - kvm kernel module - make sure /dev/kvm and /dev/net/tun have the correct privilege access. for the first one, in debian-like systems just use the following in /dev/network/interfaces: That's Debian thing. # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto br0 iface br0 inet static address 172.18.13.66 netmask 255.255.0.0 network 172.18.0.0 broadcast 172.18.255.255 gateway 172.18.0.1 bridge_ports eth0 that makes br0 my main interface, and adds eth0 to it. when i'm not running any VM, it doesn't interfere in any way, except for any utilities that default to eth0... if that were a problem, i could simply rename eth0=peth0 and br0=eth0 (i think the Xen scripts do similar tricks) That's an interesting trick. I don't know of any problems I'm having which require it, but a useful thing to consider. when that's set, /etc/qemu-ifup just have to setup the tun/tap interface and add to the bridge: #!/bin/sh ifconfig $1 0.0.0.0 promisc up brctl addif br0 $1 and that's it! no need to meddle with iptables. note that i don't even set the IP, the VM is connected to the LAN, and it setups it's own IP from inside Not being a trusting person I find that a bridge is an ineffective firewall, but with a bit of trickery that could live on the VM, to the extent it's needed. Now the sets up its own IP is a mystery, since there's no place I have told it what the IP of the machine it replaces might be. I did take the obvious step of setting the macadrs of the tap to that of the NIC in the original machine, but here I find a problem, at boot DHCP is not being used, or perhaps the issue is that some internal kvm DHCP service is being used instead of sending the requests out and letting my server provide the IP (and gateway, and nameservice, and etc). Setting up the IP and routing by hand does result in a working configuration, however, so other than the lack of control from using iptables to forward packets, it works well. If the DHCP worked as expected it would really be easy. hope that helps I thank you for sharing your info, it was a good starting point even though some of the steps were not portable. Well, it provides an easier way to get things working, there's one case where the iptables is still desirable, but that is a corner case for sure. Modulo the DHCP issue it works well, so I can say it did help, although not in the way you expected, I suspect. I'm going to write it up while I can remember what I did and understand my notes. I have a bunch of tcpdump files from the physical NIC (eth0) and the bridge (br0), and wireshark, so I may get some idea of why DHCP isn't working, that would finish the job in most cases. Even if I have to do a bit of manual setup, it's faster than setting up iptables, and acceptably secure as long as the kvm host is at least as secure as the original. -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2026321 ] info cpus crashes KVM with -smp 2+
Bugs item #2026321, was opened at 2008-07-24 10:32 Message generated for change (Comment added) made by danv You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2026321group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: info cpus crashes KVM with -smp 2+ Initial Comment: CPU: Intel Core 2 Quad Q6600 Dist: Ubuntu 8.04.1 amd64 desktop Kernel: 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux Running KVM-70 or KVM-71 with -smp 2 seems to have no effect on the guest (tested both RHEL 4.0 and WinXP guests). The guest fails to see more than one CPU, and typing info cpus in the monitor makes KVM crash instantly (though if you're quick you can see it output info about 2 VCPUs before crashing). -- Comment By: Daniel van Vugt (danv) Date: 2008-07-24 13:10 Message: Logged In: YES user_id=566150 Originator: YES Yes, OK. I got it working with another guest: Ubuntu 6.06.1 server with -smp 2. So I blame the first two guest OS's for not seeing the second CPU. Now the only problem is the crash, so I've updated the summary. -- Comment By: Brian Jackson (iggy_cav) Date: 2008-07-24 11:03 Message: Logged In: YES user_id=611130 Originator: NO I don't know about RHEL 4, but if you installed XP without -smp 1 then it installs a uniprocessor HAL, which will never see more than one cpu. I also tried info cpus and it worked fine. I'm running kvm.git from 20080720 (tagged kvm-72rc1). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2026321group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2026321 ] info cpus crashes KVM with -smp 2+
Bugs item #2026321, was opened at 2008-07-24 10:32 Message generated for change (Comment added) made by danv You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2026321group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: info cpus crashes KVM with -smp 2+ Initial Comment: CPU: Intel Core 2 Quad Q6600 Dist: Ubuntu 8.04.1 amd64 desktop Kernel: 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux Running KVM-70 or KVM-71 with -smp 2 seems to have no effect on the guest (tested both RHEL 4.0 and WinXP guests). The guest fails to see more than one CPU, and typing info cpus in the monitor makes KVM crash instantly (though if you're quick you can see it output info about 2 VCPUs before crashing). -- Comment By: Daniel van Vugt (danv) Date: 2008-07-24 13:11 Message: Logged In: YES user_id=566150 Originator: YES Note also that the crash does not happen with -no-kvm. -- Comment By: Daniel van Vugt (danv) Date: 2008-07-24 13:10 Message: Logged In: YES user_id=566150 Originator: YES Yes, OK. I got it working with another guest: Ubuntu 6.06.1 server with -smp 2. So I blame the first two guest OS's for not seeing the second CPU. Now the only problem is the crash, so I've updated the summary. -- Comment By: Brian Jackson (iggy_cav) Date: 2008-07-24 11:03 Message: Logged In: YES user_id=611130 Originator: NO I don't know about RHEL 4, but if you installed XP without -smp 1 then it installs a uniprocessor HAL, which will never see more than one cpu. I also tried info cpus and it worked fine. I'm running kvm.git from 20080720 (tagged kvm-72rc1). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2026321group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2019053 ] tbench fails on guest when AMD NPT enabled
Bugs item #2019053, was opened at 2008-07-16 00:10 Message generated for change (Comment added) made by awwy You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2019053group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: amd Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Williamson (alex_williamson) Assigned to: Nobody/Anonymous (nobody) Summary: tbench fails on guest when AMD NPT enabled Initial Comment: Running on a dual-socket system with AMD 2356 quad-core processors (8 total cores), 32GB RAM, Ubuntu Hardy 2.6.24-19-generic (64bit) with kvm-71 userspace and kernel modules. With no module options, dmesg confirms: kvm: Nested Paging enabled Start guest with: /usr/local/kvm/bin/qemu-system-x86_64 -hda /dev/VM/Ubuntu64 -m 1024 -net nic,model=e1000,mac=de:ad:be:ef:00:01 -net tap,script=/root/bin/br0-ifup -smp 8 -vnc :0 Guest VM is also Ubuntu Hardy 64bit. On the guest run 'tbench 16 tbench server'. System running tbench_srv is a different system in my case. The tbench client will fail randomly, often quietly with Child failed with status 1, but sometimes more harshly with a glibc double free error. If I unload the modules and reload w/o npt: modprobe -r kvm-amd modprobe -r kvm modprobe kvm-amd npt=0 dmesg confirms: kvm: Nested Paging disabled The tbench test now runs over and over successfully. The test also runs fine on an Intel E5450 (no EPT). -- Comment By: Alexander Graf (awwy) Date: 2008-07-24 05:45 Message: Logged In: YES user_id=376328 Originator: NO I'm seeing random segfaults when using NPT on a host kernel = 2.6.23. So far I have not been able to reproduce my test case breakages with an openSUSE 10.3 kernel though, so could you please test that and verify if tbench works for you on openSUSE 10.3? It does break with 11.0. I have the feeling that we're seeing the same problem here. -- Comment By: Alex Williamson (alex_williamson) Date: 2008-07-16 15:18 Message: Logged In: YES user_id=333914 Originator: YES No, I added mlockall(MCL_CURRENT | MCL_FUTURE) to qemu/vl.c:main() and it makes no difference. I'm only starting a 1G guest on an otherwise idle 32G host, so host memory pressure is pretty light. -- Comment By: Avi Kivity (avik) Date: 2008-07-16 14:19 Message: Logged In: YES user_id=539971 Originator: NO Strange. If you add an mlockall() to qemu startup, does the test pass? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2019053group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2019608 ] Ubuntu 8.04.1 (IA32 x86_64) - cannot install bootloader
Bugs item #2019608, was opened at 2008-07-16 15:03 Message generated for change (Comment added) made by awwy You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2019608group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Truschnigg (c0l0) Assigned to: Nobody/Anonymous (nobody) Summary: Ubuntu 8.04.1 (IA32 x86_64) - cannot install bootloader Initial Comment: CPU: Intel Core 2 Quad Q6600 (4 cores) Distro, kernel: Gentoo GNU/Linux ~amd64, Kernel 2.6.25-r6 Bitness, compiler: x86_64, GCC 4.3.1 KVM versions: kvm-70, kvm-71 When trying to install Ubuntu) either 32bit or 64bit) in a KVM guest, grub-install croaks with. The guest kernel debug ringbuffer shows the following messages: (Please see http://pasted.at/9d7e95f873.html or the attached file!) Windows XP also hangs at installing, actually before anthing substantial other than copying installation files gets done. The first phase of the install completes, however - the graphical installer that's started after the first reboot hangs indefinitely. Worked fine with version = kvm-69 with the very same settings. I'm happy to provide additional information upon request. -- Comment By: Alexander Graf (awwy) Date: 2008-07-24 05:56 Message: Logged In: YES user_id=376328 Originator: NO I am getting exactly the same error on SLES10 SP2. Running a 32-bit binary in an x86_64 SLES10SP2 guest generates a #DF on a RIP, that looks like a 32-bit mangled kernel space address (80228ca0 vs. 80228ca0). Apparently something truncates it - I'll try to bisect. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2019608group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
