Re: Amount of virtual disks with KVM
On 11/29/2009 07:58 PM, Daniel Bareiro wrote: Hi all! I'm trying to make a migration of a Xen PV virtual machine to KVM. For this I'm starting a VM with SystemRescueCD [1] of the following way: # /usr/local/kvm/bin/qemu-system-x86_64 -hda /dev/vm/hermes-disk -boot d \ -cdrom /space/isos/systemrescuecd-x86-1.3.2.iso -m 512 -daemonize -vnc \ :2 -k es -localtime -hdb hermes-raiz.raw -hdc hermes-var.raw -net \ nic,vlan=0,macaddr=00:16:3e:00:00:34 -net tap Where hermes-disk is the disk that will use the VM in the destination host, and hermes-raiz.raw and hermes-var.raw are the raw partitions that was using the Xen PV virtual machine in source host. My idea is to create the partitions in hermes-disk, to mount the raw partitions and to do cp -a to the partitions created in hermes-disk, but after boot only hermes-disk and hermes-raiz.raw are exported (like sda and sdb). Which can be the problem? -cdrom and -hdc occupy the same IDE slot (second bus, master drive). Try -hdd instead of -hdc. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: kernel/smp.c:292 smp_call_function_single [Was: mmotm 2009-11-24-16-47 uploaded]
Hello, On 11/28/2009 09:12 PM, Avi Kivity wrote: Hmm, commit 498657a moved the fire_sched_in_preempt_notifiers() call into the irqs disabled section recently. sched, kvm: Fix race condition involving sched_in_preempt_notifers In finish_task_switch(), fire_sched_in_preempt_notifiers() is called after finish_lock_switch(). However, depending on architecture, preemption can be enabled after finish_lock_switch() which breaks the semantics of preempt notifiers. So move it before finish_arch_switch(). This also makes the in- notifiers symmetric to out- notifiers in terms of locking - now both are called under rq lock. It's not a surprise that this breaks the existing code which does the smp function call. Yes, kvm expects preempt notifiers to be run with irqs enabled. Copying patch author. Hmmm... then, it's broken both ways. The previous code may get preempted after scheduling but before the notifier is run (which breaks the semantics of the callback horribly), the current code doesn't satisfy kvm's requirement. Another thing is that in the previous implementation the context is different between the 'in' and 'out' callbacks, which is subtle and nasty. Can kvm be converted to not do smp calls directly? For the time being, maybe it's best to back out the fix given that the only architecture which may be affected by the original bug is ia64 which is the only one with both kvm and the unlocked context switch. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: kernel/smp.c:292 smp_call_function_single [Was: mmotm 2009-11-24-16-47 uploaded]
On 11/30/2009 10:58 AM, Tejun Heo wrote: Hello, On 11/28/2009 09:12 PM, Avi Kivity wrote: Hmm, commit 498657a moved the fire_sched_in_preempt_notifiers() call into the irqs disabled section recently. sched, kvm: Fix race condition involving sched_in_preempt_notifers In finish_task_switch(), fire_sched_in_preempt_notifiers() is called after finish_lock_switch(). However, depending on architecture, preemption can be enabled after finish_lock_switch() which breaks the semantics of preempt notifiers. So move it before finish_arch_switch(). This also makes the in- notifiers symmetric to out- notifiers in terms of locking - now both are called under rq lock. It's not a surprise that this breaks the existing code which does the smp function call. Yes, kvm expects preempt notifiers to be run with irqs enabled. Copying patch author. Hmmm... then, it's broken both ways. The previous code may get preempted after scheduling but before the notifier is run (which breaks the semantics of the callback horribly), the current code doesn't satisfy kvm's requirement. Another thing is that in the previous implementation the context is different between the 'in' and 'out' callbacks, which is subtle and nasty. Can kvm be converted to not do smp calls directly? No. kvm uses preempt notifiers to manage extended processor registers (much like the fpu). If we're scheduled into cpu A but state is currently live on cpu B, we need to go ahead and pull it in. Technically, we can delay the IPI to happen after the sched in notifier; we can set some illegal state in cpu A and handle the exception by sending the IPI and fixing up the state. But that would be slower, and not help the problem at all since some accesses happen with interrupts disabled. Since this is essentially the same problem as the fpu, maybe we can solve it the same way. How does the fpu migrate its state across processors? One way would be to save the state when the task is selected for migration. For the time being, maybe it's best to back out the fix given that the only architecture which may be affected by the original bug is ia64 which is the only one with both kvm and the unlocked context switch. Agreed. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: kernel/smp.c:292 smp_call_function_single [Was: mmotm 2009-11-24-16-47 uploaded]
On Mon, 30 Nov 2009, Tejun Heo wrote:
Hello,
On 11/28/2009 09:12 PM, Avi Kivity wrote:
Hmm, commit 498657a moved the fire_sched_in_preempt_notifiers() call
into the irqs disabled section recently.
sched, kvm: Fix race condition involving sched_in_preempt_notifers
In finish_task_switch(), fire_sched_in_preempt_notifiers() is
called after finish_lock_switch().
However, depending on architecture, preemption can be enabled after
finish_lock_switch() which breaks the semantics of preempt
notifiers.
So move it before finish_arch_switch(). This also makes the in-
notifiers symmetric to out- notifiers in terms of locking - now
both are called under rq lock.
It's not a surprise that this breaks the existing code which does the
smp function call.
Yes, kvm expects preempt notifiers to be run with irqs enabled. Copying
patch author.
Hmmm... then, it's broken both ways. The previous code may get
preempted after scheduling but before the notifier is run (which
breaks the semantics of the callback horribly), the current code
No, it _CANNOT_ be preempted at that point:
schedule()
{
preempt_disable();
switch_to();
preempt_enable();
}
doesn't satisfy kvm's requirement. Another thing is that in the
previous implementation the context is different between the 'in' and
'out' callbacks, which is subtle and nasty. Can kvm be converted to
not do smp calls directly?
For the time being, maybe it's best to back out the fix given that the
only architecture which may be affected by the original bug is ia64
which is the only one with both kvm and the unlocked context switch.
Do you have a pointer to the original bug report ?
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] core: clean up user return notifers use of per_cpu
Instead of using per_cpu(..., raw_smp_processor_id()), use __get_cpu_var(...).
Signed-off-by: Avi Kivity a...@redhat.com
---
kernel/user-return-notifier.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/user-return-notifier.c b/kernel/user-return-notifier.c
index 03e2d6f..eb27fd3 100644
--- a/kernel/user-return-notifier.c
+++ b/kernel/user-return-notifier.c
@@ -6,8 +6,6 @@
static DEFINE_PER_CPU(struct hlist_head, return_notifier_list);
-#define URN_LIST_HEAD per_cpu(return_notifier_list, raw_smp_processor_id())
-
/*
* Request a notification when the current cpu returns to userspace. Must be
* called in atomic context. The notifier will also be called in atomic
@@ -16,7 +14,7 @@ static DEFINE_PER_CPU(struct hlist_head,
return_notifier_list);
void user_return_notifier_register(struct user_return_notifier *urn)
{
set_tsk_thread_flag(current, TIF_USER_RETURN_NOTIFY);
- hlist_add_head(urn-link, URN_LIST_HEAD);
+ hlist_add_head(urn-link, __get_cpu_var(return_notifier_list));
}
EXPORT_SYMBOL_GPL(user_return_notifier_register);
@@ -27,7 +25,7 @@ EXPORT_SYMBOL_GPL(user_return_notifier_register);
void user_return_notifier_unregister(struct user_return_notifier *urn)
{
hlist_del(urn-link);
- if (hlist_empty(URN_LIST_HEAD))
+ if (hlist_empty(__get_cpu_var(return_notifier_list)))
clear_tsk_thread_flag(current, TIF_USER_RETURN_NOTIFY);
}
EXPORT_SYMBOL_GPL(user_return_notifier_unregister);
--
1.6.5.2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/12] Maintain preemptability count even for !CONFIG_PREEMPT kernels
On Tue, Nov 24, 2009 at 09:14:03AM -0600, Christoph Lameter wrote: On Tue, 24 Nov 2009, Gleb Natapov wrote: On Mon, Nov 23, 2009 at 11:30:02AM -0600, Christoph Lameter wrote: This adds significant overhead for the !PREEMPT case adding lots of code in critical paths all over the place. I want to measure it. Can you suggest benchmarks to try? AIM9 (reaim9)? Below are results for kernel 2.6.32-rc8 with and without the patch (only this single patch is applied). test name with (stddev)without (stddev) === jmp_test 57853.762 ( 1086.51) 55664.287 ( 5152.14)3.93% stream_pipe 10286.967 ( 132.01) 11396.327 ( 306.01) -9.73% new_raph 12573.395 (2.64) 12535.764 ( 85.14)0.30% sync_disk_rw 0.100 (0.00) 0.100 (0.00) -0.44% udp_test 4008.058 ( 37.57) 3774.514 ( 22.03)6.19% add_long68.542 (0.00) 68.530 (0.01)0.02% exec_test 181.615 (0.46)184.503 (0.42) -1.57% div_double 114.209 (0.02)114.230 (0.03) -0.02% mem_rtns_1 283.733 (3.27)285.936 (2.24) -0.77% sync_disk_cp 0.043 (0.00) 0.043 (0.00)0.03% fun_cal2 780.701 (0.16)780.867 (0.07) -0.02% matrix_rtns 70160.568 ( 28.58) 70181.900 ( 16.46) -0.03% fun_cal1 780.701 (0.16)780.763 (0.13) -0.01% div_int219.216 (0.03)219.264 (0.04) -0.02% pipe_cpy 16239.120 ( 468.99) 16727.067 ( 280.27) -2.92% fifo_test12864.276 ( 242.82) 13383.616 ( 199.31) -3.88% sync_disk_wrt0.043 (0.00) 0.043 (0.00) -0.11% mul_long 4276.703 (0.79) 4277.528 (0.65) -0.02% num_rtns_14308.165 (5.99) 4306.133 (5.84)0.05% disk_src 1507.993 (8.04) 1586.100 (5.44) -4.92% mul_short 3422.840 (0.31) 3423.280 (0.24) -0.01% series_1121706.708 ( 266.62) 121356.355 ( 982.04)0.29% mul_int 4277.353 (0.45) 4277.953 (0.34) -0.01% mul_float 99.947 (0.02) 99.947 (0.02) -0.00% link_test 2319.090 ( 12.51) 2466.564 (1.52) -5.98% fun_cal15 380.836 (0.06)380.876 (0.10) -0.01% trig_rtns 163.416 (0.13)163.185 (0.51)0.14% fun_cal915.226 (4.56)902.033 (1.44)1.46% misc_rtns_1 4285.322 ( 18.72) 4282.907 ( 27.07)0.06% brk_test 221.167 (8.98)230.345 (7.98) -3.98% add_float 133.242 (0.02)133.249 (0.02) -0.01% page_test 284.488 (3.71)284.180 ( 13.91)0.11% div_long85.364 (0.27) 85.222 (0.02)0.17% dir_rtns_1 207.953 (2.56)212.532 (0.59) -2.15% disk_cp 66.449 (0.43) 65.754 (0.61)1.06% sieve 23.538 (0.01) 23.599 (0.11) -0.26% tcp_test 2085.428 ( 18.43) 2059.062 (5.52)1.28% disk_wrt81.839 (0.16) 82.652 (0.41) -0.98% mul_double 79.951 (0.01) 79.961 (0.02) -0.01% fork_test 57.408 (0.43) 57.835 (0.27) -0.74% add_short 171.326 (0.03)171.314 (0.01)0.01% creat-clo 395.995 (3.63)403.918 (2.74) -1.96% sort_rtns_1276.833 ( 31.80)290.855 (0.46) -4.82% add_int 79.961 (0.02) 79.967 (0.00) -0.01% disk_rr 67.635 (0.23) 68.282 (0.59) -0.95% div_short 210.318 (0.04)210.365 (0.05) -0.02% disk_rw 57.041 (0.26) 57.470 (0.31) -0.75% dgram_pipe 10088.191 ( 86.81) 9848.119 ( 406.33)2.44% shell_rtns_3 681.882 (3.30)693.734 (2.67) -1.71% shell_rtns_2 681.721 (3.24)693.307 (2.90) -1.67% shell_rtns_1 681.116 (3.46)692.302 (3.16) -1.62% div_float 114.224 (0.02)114.230 (0.00) -0.01% ram_copy217812.436 ( 615.62) 218160.548 ( 135.66) -0.16% shared_memory11022.611 ( 20.75) 10870.031 ( 61.44)1.40% signal_test700.907 (1.42)711.253 (0.49) -1.46% add_double 88.836 (0.00) 88.837 (0.00) -0.00% array_rtns 119.369 (0.06)119.182 (0.36)0.16% string_rtns 97.107 (0.21) 97.160 (0.22) -0.05% disk_rd626.890 ( 18.25)586.034 (5.58)6.97% -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/12] Maintain preemptability count even for !CONFIG_PREEMPT kernels
On Mon, Nov 30, 2009 at 12:56:12PM +0200, Gleb Natapov wrote: On Tue, Nov 24, 2009 at 09:14:03AM -0600, Christoph Lameter wrote: On Tue, 24 Nov 2009, Gleb Natapov wrote: On Mon, Nov 23, 2009 at 11:30:02AM -0600, Christoph Lameter wrote: This adds significant overhead for the !PREEMPT case adding lots of code in critical paths all over the place. I want to measure it. Can you suggest benchmarks to try? AIM9 (reaim9)? Below are results for kernel 2.6.32-rc8 with and without the patch (only this single patch is applied). Forgot to tell. The results are average between 5 different runs. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/12] Maintain preemptability count even for !CONFIG_PREEMPT kernels
On Mon, 2009-11-30 at 12:58 +0200, Gleb Natapov wrote: On Mon, Nov 30, 2009 at 12:56:12PM +0200, Gleb Natapov wrote: On Tue, Nov 24, 2009 at 09:14:03AM -0600, Christoph Lameter wrote: On Tue, 24 Nov 2009, Gleb Natapov wrote: On Mon, Nov 23, 2009 at 11:30:02AM -0600, Christoph Lameter wrote: This adds significant overhead for the !PREEMPT case adding lots of code in critical paths all over the place. I want to measure it. Can you suggest benchmarks to try? AIM9 (reaim9)? Below are results for kernel 2.6.32-rc8 with and without the patch (only this single patch is applied). Forgot to tell. The results are average between 5 different runs. Would be good to also report the variance over those 5 runs, allows us to see if the difference is within the noise. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/12] Maintain preemptability count even for !CONFIG_PREEMPT kernels
On 11/30/2009 12:59 PM, Peter Zijlstra wrote: Forgot to tell. The results are average between 5 different runs. Would be good to also report the variance over those 5 runs, allows us to see if the difference is within the noise. That's the stddev column. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH tip/sched/urgent] sched: revert 498657a478c60be092208422fefa9c7b248729c2
498657a478c60be092208422fefa9c7b248729c2 incorrectly assumed that
preempt wasn't disabled around context_switch() and thus was fixing
imaginary problem. It also broke kvm because it depended on
-sched_in() to be called with irq enabled so that it can do smp calls
from there.
Revert the incorrect commit and add comment describing different
contexts under with the two callbacks are invoked.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@elte.hu
Cc: Avi Kivity a...@redhat.com
---
Again, my apologies for the unnecessary fuss. I for some reason was
thinking schedule_tail() is always called after context_switch() and
the ifdefed preemption enable there led me to think that at that point
preemption was enabled once lock switch is over.
Thank you.
include/linux/preempt.h |4
kernel/sched.c |2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/preempt.h b/include/linux/preempt.h
index 72b1a10..736892c 100644
--- a/include/linux/preempt.h
+++ b/include/linux/preempt.h
@@ -105,6 +105,10 @@ struct preempt_notifier;
* @sched_out: we've just been preempted
*notifier: struct preempt_notifier for the task being preempted
*next: the task that's kicking us out
+ *
+ * Please note that sched_in and out are called under different
+ * contexts. sched_in is called with rq lock held and irq disabled
+ * while sched_out is called without rq lock and irq enabled.
*/
struct preempt_ops {
void (*sched_in)(struct preempt_notifier *notifier, int cpu);
diff --git a/kernel/sched.c b/kernel/sched.c
index 3c91f11..e36c868 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2758,9 +2758,9 @@ static void finish_task_switch(struct rq *rq, struct
task_struct *prev)
prev_state = prev-state;
finish_arch_switch(prev);
perf_event_task_sched_in(current, cpu_of(rq));
- fire_sched_in_preempt_notifiers(current);
finish_lock_switch(rq, prev);
+ fire_sched_in_preempt_notifiers(current);
if (mm)
mmdrop(mm);
if (unlikely(prev_state == TASK_DEAD)) {
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/12] Maintain preemptability count even for !CONFIG_PREEMPT kernels
On Mon, 2009-11-30 at 11:59 +0100, Peter Zijlstra wrote: On Mon, 2009-11-30 at 12:58 +0200, Gleb Natapov wrote: On Mon, Nov 30, 2009 at 12:56:12PM +0200, Gleb Natapov wrote: On Tue, Nov 24, 2009 at 09:14:03AM -0600, Christoph Lameter wrote: On Tue, 24 Nov 2009, Gleb Natapov wrote: On Mon, Nov 23, 2009 at 11:30:02AM -0600, Christoph Lameter wrote: This adds significant overhead for the !PREEMPT case adding lots of code in critical paths all over the place. I want to measure it. Can you suggest benchmarks to try? AIM9 (reaim9)? Below are results for kernel 2.6.32-rc8 with and without the patch (only this single patch is applied). Forgot to tell. The results are average between 5 different runs. Would be good to also report the variance over those 5 runs, allows us to see if the difference is within the noise. Got pointed to the fact that there is a stddev column right there. Must be Monday or something ;-) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH tip/sched/urgent] sched: revert 498657a478c60be092208422fefa9c7b248729c2
On 11/30/2009 01:02 PM, Tejun Heo wrote: 498657a478c60be092208422fefa9c7b248729c2 incorrectly assumed that preempt wasn't disabled around context_switch() and thus was fixing imaginary problem. It also broke kvm because it depended on -sched_in() to be called with irq enabled so that it can do smp calls from there. Revert the incorrect commit and add comment describing different contexts under with the two callbacks are invoked. *notifier: struct preempt_notifier for the task being preempted *next: the task that's kicking us out + * + * Please note that sched_in and out are called under different + * contexts. sched_in is called with rq lock held and irq disabled + * while sched_out is called without rq lock and irq enabled. */ Is this transposed? sched_in must be called with interrupts enabled for the kvm IPI to work. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: guest gets stuck on the migration from AMD to Intel
Avi Kivity wrote: Please set up serial console for the guest and any post any detailed messages printed there (e.g. a stacktrace). This is what I got on the new host: [ 677.532010] BUG: soft lockup - CPU#0 stuck for 61s! [ntpd:1665] [ 677.532010] Modules linked in: loop serio_raw snd_pcsp psmouse virtio_balloon snd_pcm snd_timer snd soundcore snd_page_alloc evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd floppy ide_core ehci_hcd virtio_pci virtio_ring virtio thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 677.532010] CPU 0: [ 677.532010] Modules linked in: loop serio_raw snd_pcsp psmouse virtio_balloon snd_pcm snd_timer snd soundcore snd_page_alloc evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd floppy ide_core ehci_hcd virtio_pci virtio_ring virtio thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 677.532010] Pid: 1665, comm: ntpd Not tainted 2.6.30-2-amd64 #1 [ 677.532010] RIP: 0010:[8022726e] [8022726e] kvm_deferred_mmu_op+0x57/0xd2 [ 677.532010] RSP: 0018:88003d40dc68 EFLAGS: 0293 [ 677.532010] RAX: RBX: 0016 RCX: 3d40dcaa [ 677.532010] RDX: RSI: 0018 RDI: 88003d40dcaa [ 677.532010] RBP: 802105ce R08: 0080 R09: e2d2b2b8 [ 677.532010] R10: 00039d69 R11: 0001 R12: 0001 [ 677.532010] R13: 8800e808 R14: 3f401980 R15: [ 677.532010] FS: 7f932e5b36f0() GS:88000200() knlGS: [ 677.532010] CS: 0010 DS: ES: CR0: 80050033 [ 677.532010] CR2: 7f932e5bd000 CR3: 3cd9c000 CR4: 06e0 [ 677.532010] DR0: DR1: DR2: [ 677.532010] DR3: DR6: 0ff0 DR7: 0400 [ 677.532010] Call Trace: [ 677.532010] [80227262] ? kvm_deferred_mmu_op+0x4b/0xd2 [ 677.532010] [80227339] ? kvm_mmu_write+0x2b/0x31 [ 677.532010] [802a6081] ? handle_mm_fault+0x283/0x700 [ 677.532010] [8022cce1] ? do_page_fault+0x1f3/0x208 [ 677.532010] [804b5d55] ? page_fault+0x25/0x30 [ 677.532010] [80352fed] ? copy_user_generic_string+0x2d/0x40 [ 677.532010] [802d6d1a] ? seq_read+0x300/0x380 [ 677.532010] [802ff052] ? proc_reg_read+0x6f/0x8a [ 677.532010] [802c15ed] ? vfs_read+0xa6/0xff [ 677.532010] [802c1702] ? sys_read+0x45/0x6e [ 677.532010] [8020fa42] ? system_call_fastpath+0x16/0x1b [ 743.032010] BUG: soft lockup - CPU#0 stuck for 61s! [ntpd:1665] [ 743.032010] Modules linked in: loop serio_raw snd_pcsp psmouse virtio_balloon snd_pcm snd_timer snd soundcore snd_page_alloc evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd floppy ide_core ehci_hcd virtio_pci virtio_ring virtio thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 743.032010] CPU 0: [ 743.032010] Modules linked in: loop serio_raw snd_pcsp psmouse virtio_balloon snd_pcm snd_timer snd soundcore snd_page_alloc evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd floppy ide_core ehci_hcd virtio_pci virtio_ring virtio thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 743.032010] Pid: 1665, comm: ntpd Not tainted 2.6.30-2-amd64 #1 [ 743.032010] RIP: 0010:[8022726e] [8022726e] kvm_deferred_mmu_op+0x57/0xd2 [ 743.032010] RSP: 0018:88003d40dc68 EFLAGS: 0293 [ 743.032010] RAX: RBX: 0016 RCX: 3d40dcaa [ 743.032010] RDX: RSI: 0018 RDI: 88003d40dcaa [ 743.032010] RBP: 802105ce R08: 0080 R09: e2d2b2b8 [ 743.032010] R10: 00039d69 R11: 0001 R12: 0001 [ 743.032010] R13: 8800e808 R14: 3f401980 R15: [ 743.032010] FS: 7f932e5b36f0() GS:88000200() knlGS: [ 743.032010] CS: 0010 DS: ES: CR0: 80050033 [ 743.032010] CR2: 7f932e5bd000 CR3: 3cd9c000 CR4: 06e0 [ 743.032010] DR0: DR1: DR2: [ 743.032010] DR3: DR6: 0ff0 DR7: 0400 [ 743.032010] Call Trace: [ 743.032010] [80227262] ? kvm_deferred_mmu_op+0x4b/0xd2 [ 743.032010] [80227339] ? kvm_mmu_write+0x2b/0x31 [ 743.032010] [802a6081] ? handle_mm_fault+0x283/0x700 [ 743.032010] [8022cce1] ? do_page_fault+0x1f3/0x208 [ 743.032010]
Re: guest gets stuck on the migration from AMD to Intel
Harald Dunkel wrote: Avi Kivity wrote: Please set up serial console for the guest and any post any detailed messages printed there (e.g. a stacktrace). This is what I got on the new host: [ 677.532010] BUG: soft lockup - CPU#0 stuck for 61s! [ntpd:1665] [ 677.532010] Modules linked in: loop serio_raw snd_pcsp psmouse virtio_balloon snd_pcm snd_timer snd soundcore snd_page_alloc evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd floppy ide_core ehci_hcd virtio_pci virtio_ring virtio thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 677.532010] CPU 0: [ 677.532010] Modules linked in: loop serio_raw snd_pcsp psmouse virtio_balloon snd_pcm snd_timer snd soundcore snd_page_alloc evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd floppy ide_core ehci_hcd virtio_pci virtio_ring virtio thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 677.532010] Pid: 1665, comm: ntpd Not tainted 2.6.30-2-amd64 #1 Sorry, wrong kernel. Here is the output for 2.6.31.6: [ 374.736010] BUG: soft lockup - CPU#0 stuck for 61s! [ntpd:1657] [ 374.736010] Modules linked in: ipv6 loop snd_pcm snd_timer snd soundcore snd_page_alloc virtio_balloon psmouse serio_raw pcspkr evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic ata_piix libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd virtio_pci virtio_ring virtio floppy ehci_hcd ide_core thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 374.736010] CPU 0: [ 374.736010] Modules linked in: ipv6 loop snd_pcm snd_timer snd soundcore snd_page_alloc virtio_balloon psmouse serio_raw pcspkr evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic ata_piix libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd virtio_pci virtio_ring virtio floppy ehci_hcd ide_core thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 374.736010] Pid: 1657, comm: ntpd Not tainted 2.6.31.6 #1 [ 374.736010] RIP: 0010:[8102524d] [8102524d] kvm_deferred_mmu_op+0x58/0xd6 [ 374.736010] RSP: 0018:88003d8ffc68 EFLAGS: 0293 [ 374.736010] RAX: RBX: 0016 RCX: 3d8ffcaa [ 374.736010] RDX: RSI: 0018 RDI: 88003d8ffcaa [ 374.736010] RBP: 8100c5ae R08: 0080 R09: eaa8a598 [ 374.736010] R10: 0003a0d5 R11: 0001 R12: 000280da [ 374.736010] R13: 3d8ffe48 R14: 88001700 R15: fdf0 [ 374.736010] FS: 7fa19b21f6f0() GS:8800015ac000() knlGS: [ 374.736010] CS: 0010 DS: ES: CR0: 80050033 [ 374.736010] CR2: 7fa19b229000 CR3: 3dcad000 CR4: 06f0 [ 374.736010] DR0: DR1: DR2: [ 374.736010] DR3: DR6: 0ff0 DR7: 0400 [ 374.736010] Call Trace: [ 374.736010] [81025241] ? kvm_deferred_mmu_op+0x4c/0xd6 [ 374.736010] [8102531b] ? kvm_mmu_write+0x2b/0x31 [ 374.736010] [810b7840] ? handle_mm_fault+0x300/0x77d [ 374.736010] [8111b49f] ? seq_release_net+0x0/0x3b [ 374.736010] [81028f29] ? do_page_fault+0x25f/0x27b [ 374.736010] [812a19a5] ? page_fault+0x25/0x30 [ 374.736010] [81171bfd] ? copy_user_generic_string+0x2d/0x40 [ 374.736010] [810ea37c] ? seq_read+0x300/0x380 [ 374.736010] [81113e9d] ? proc_reg_read+0x6d/0x88 [ 374.736010] [810d3ca2] ? vfs_read+0xaa/0x166 [ 374.736010] [810d3e1a] ? sys_read+0x45/0x6e [ 374.736010] [8100ba02] ? system_call_fastpath+0x16/0x1b : : Regards Harri -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qemu-kvm: fix __user export
__user macro does not appear in exported headers
and should not be in headers qemu-kvm includes.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
kvm/include/linux/kvm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kvm/include/linux/kvm.h b/kvm/include/linux/kvm.h
index 92045a9..db10887 100644
--- a/kvm/include/linux/kvm.h
+++ b/kvm/include/linux/kvm.h
@@ -309,7 +309,7 @@ struct kvm_dirty_log {
__u32 slot;
__u32 padding1;
union {
- void __user *dirty_bitmap; /* one bit per page */
+ void *dirty_bitmap; /* one bit per page */
__u64 padding2;
};
};
--
1.6.5.2.143.g8cc62
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'
El Sun, 29 Nov 2009 23:31:45 + Nix n...@esperi.org.uk escribió: On 29 Nov 2009, Avi Kivity stated: [...] Anyone know? When I install the infamous nvidia driver I use. « sudo stop gdm » there are a start and restart aliases too see « man initctl ». Sometimes is not enough though and I have to stop gdm and then pkill the X server signature.asc Description: PGP signature
Re: guest gets stuck on the migration from AMD to Intel
On 11/30/2009 01:54 PM, Harald Dunkel wrote: Sorry, wrong kernel. Here is the output for 2.6.31.6: [ 374.736010] BUG: soft lockup - CPU#0 stuck for 61s! [ntpd:1657] [ 374.736010] Modules linked in: ipv6 loop snd_pcm snd_timer snd soundcore snd_page_alloc virtio_balloon psmouse serio_raw pcspkr evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic ata_piix libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd virtio_pci virtio_ring virtio floppy ehci_hcd ide_core thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 374.736010] CPU 0: [ 374.736010] Modules linked in: ipv6 loop snd_pcm snd_timer snd soundcore snd_page_alloc virtio_balloon psmouse serio_raw pcspkr evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic ata_piix libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd virtio_pci virtio_ring virtio floppy ehci_hcd ide_core thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 374.736010] Pid: 1657, comm: ntpd Not tainted 2.6.31.6 #1 [ 374.736010] RIP: 0010:[8102524d] [8102524d] kvm_deferred_mmu_op+0x58/0xd6 [ 374.736010] RSP: 0018:88003d8ffc68 EFLAGS: 0293 [ 374.736010] RAX: RBX: 0016 RCX: 3d8ffcaa [ 374.736010] RDX: RSI: 0018 RDI: 88003d8ffcaa [ 374.736010] RBP: 8100c5ae R08: 0080 R09: eaa8a598 [ 374.736010] R10: 0003a0d5 R11: 0001 R12: 000280da [ 374.736010] R13: 3d8ffe48 R14: 88001700 R15: fdf0 [ 374.736010] FS: 7fa19b21f6f0() GS:8800015ac000() knlGS: [ 374.736010] CS: 0010 DS: ES: CR0: 80050033 [ 374.736010] CR2: 7fa19b229000 CR3: 3dcad000 CR4: 06f0 [ 374.736010] DR0: DR1: DR2: [ 374.736010] DR3: DR6: 0ff0 DR7: 0400 [ 374.736010] Call Trace: [ 374.736010] [81025241] ? kvm_deferred_mmu_op+0x4c/0xd6 [ 374.736010] [8102531b] ? kvm_mmu_write+0x2b/0x31 [ 374.736010] [810b7840] ? handle_mm_fault+0x300/0x77d [ 374.736010] [8111b49f] ? seq_release_net+0x0/0x3b [ 374.736010] [81028f29] ? do_page_fault+0x25f/0x27b [ 374.736010] [812a19a5] ? page_fault+0x25/0x30 [ 374.736010] [81171bfd] ? copy_user_generic_string+0x2d/0x40 [ 374.736010] [810ea37c] ? seq_read+0x300/0x380 [ 374.736010] [81113e9d] ? proc_reg_read+0x6d/0x88 [ 374.736010] [810d3ca2] ? vfs_read+0xaa/0x166 [ 374.736010] [810d3e1a] ? sys_read+0x45/0x6e [ 374.736010] [8100ba02] ? system_call_fastpath+0x16/0x1b : : Hm, pvmmu. Can you provide /proc/cpuinfo on the source (AMD) host? Marcelo, shouldn't this be inactive after migration from AMD to Intel? Or maybe hypercall patching is screwing up? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: guest gets stuck on the migration from AMD to Intel
(resend with better cc list) On 11/30/2009 01:54 PM, Harald Dunkel wrote: Sorry, wrong kernel. Here is the output for 2.6.31.6: [ 374.736010] BUG: soft lockup - CPU#0 stuck for 61s! [ntpd:1657] [ 374.736010] Modules linked in: ipv6 loop snd_pcm snd_timer snd soundcore snd_page_alloc virtio_balloon psmouse serio_raw pcspkr evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic ata_piix libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd virtio_pci virtio_ring virtio floppy ehci_hcd ide_core thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 374.736010] CPU 0: [ 374.736010] Modules linked in: ipv6 loop snd_pcm snd_timer snd soundcore snd_page_alloc virtio_balloon psmouse serio_raw pcspkr evdev i2c_piix4 i2c_core button processor reiserfs ide_cd_mod cdrom ata_generic ata_piix libata scsi_mod ide_pci_generic virtio_blk virtio_net piix uhci_hcd virtio_pci virtio_ring virtio floppy ehci_hcd ide_core thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 374.736010] Pid: 1657, comm: ntpd Not tainted 2.6.31.6 #1 [ 374.736010] RIP: 0010:[8102524d] [8102524d] kvm_deferred_mmu_op+0x58/0xd6 [ 374.736010] RSP: 0018:88003d8ffc68 EFLAGS: 0293 [ 374.736010] RAX: RBX: 0016 RCX: 3d8ffcaa [ 374.736010] RDX: RSI: 0018 RDI: 88003d8ffcaa [ 374.736010] RBP: 8100c5ae R08: 0080 R09: eaa8a598 [ 374.736010] R10: 0003a0d5 R11: 0001 R12: 000280da [ 374.736010] R13: 3d8ffe48 R14: 88001700 R15: fdf0 [ 374.736010] FS: 7fa19b21f6f0() GS:8800015ac000() knlGS: [ 374.736010] CS: 0010 DS: ES: CR0: 80050033 [ 374.736010] CR2: 7fa19b229000 CR3: 3dcad000 CR4: 06f0 [ 374.736010] DR0: DR1: DR2: [ 374.736010] DR3: DR6: 0ff0 DR7: 0400 [ 374.736010] Call Trace: [ 374.736010] [81025241] ? kvm_deferred_mmu_op+0x4c/0xd6 [ 374.736010] [8102531b] ? kvm_mmu_write+0x2b/0x31 [ 374.736010] [810b7840] ? handle_mm_fault+0x300/0x77d [ 374.736010] [8111b49f] ? seq_release_net+0x0/0x3b [ 374.736010] [81028f29] ? do_page_fault+0x25f/0x27b [ 374.736010] [812a19a5] ? page_fault+0x25/0x30 [ 374.736010] [81171bfd] ? copy_user_generic_string+0x2d/0x40 [ 374.736010] [810ea37c] ? seq_read+0x300/0x380 [ 374.736010] [81113e9d] ? proc_reg_read+0x6d/0x88 [ 374.736010] [810d3ca2] ? vfs_read+0xaa/0x166 [ 374.736010] [810d3e1a] ? sys_read+0x45/0x6e [ 374.736010] [8100ba02] ? system_call_fastpath+0x16/0x1b : : Hm, pvmmu. Can you provide /proc/cpuinfo on the source (AMD) host? Marcelo, shouldn't this be inactive after migration from AMD to Intel? Or maybe hypercall patching is screwing up? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PPC: Sync guest visible MMU state
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This patch exports enough of the MMU segment state to userspace to make
debugging work and thus also includes the groundwork for migration.
Signed-off-by: Alexander Graf ag...@suse.de
---
Ben, please take this patch in your tree.
v2 - v3:
- don't use anonymous unions/structs
v3 - v4:
- don't change API to what it was before
---
arch/powerpc/include/asm/kvm.h| 18 +++-
arch/powerpc/include/asm/kvm_asm.h|1 +
arch/powerpc/include/asm/kvm_book3s.h |3 ++
arch/powerpc/kvm/book3s.c | 49 +
arch/powerpc/kvm/book3s_64_emulate.c | 38 +++--
arch/powerpc/kvm/book3s_64_mmu.c |2 +
arch/powerpc/kvm/powerpc.c|3 ++
include/linux/kvm.h |3 ++
8 files changed, 101 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index c9ca97f..81f3b0b 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -47,7 +47,23 @@ struct kvm_regs {
struct kvm_sregs {
__u32 pvr;
- char pad[1020];
+ union {
+ struct {
+ __u64 sdr1;
+ struct {
+ struct {
+ __u64 slbe;
+ __u64 slbv;
+ } slb[64];
+ } ppc64;
+ struct {
+ __u32 sr[16];
+ __u64 ibat[8];
+ __u64 dbat[8];
+ } ppc32;
+ } s;
+ __u8 pad[1020];
+ } u;
};
struct kvm_fpu {
diff --git a/arch/powerpc/include/asm/kvm_asm.h
b/arch/powerpc/include/asm/kvm_asm.h
index 19ddb35..af2abe7 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -87,6 +87,7 @@
#define BOOK3S_IRQPRIO_MAX 16
#define BOOK3S_HFLAG_DCBZ320x1
+#define BOOK3S_HFLAG_SLB 0x2
#define RESUME_FLAG_NV (10) /* Reload guest nonvolatile state? */
#define RESUME_FLAG_HOST(11) /* Resume host? */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index c601133..74b7369 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -46,6 +46,7 @@ struct kvmppc_sr {
};
struct kvmppc_bat {
+ u64 raw;
u32 bepi;
u32 bepi_mask;
bool vs;
@@ -113,6 +114,8 @@ extern struct kvmppc_pte *kvmppc_mmu_find_pte(struct
kvm_vcpu *vcpu, u64 ea, boo
extern int kvmppc_ld(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr,
bool data);
extern int kvmppc_st(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr);
extern void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, unsigned int
vec);
+extern void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat,
+ bool upper, u32 val);
extern u32 kvmppc_trampoline_lowmem;
extern u32 kvmppc_trampoline_enter;
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 42037d4..3e294bd 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -281,6 +281,7 @@ void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu)
void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
{
+ vcpu-arch.hflags = ~BOOK3S_HFLAG_SLB;
vcpu-arch.pvr = pvr;
if ((pvr = 0x33) (pvr 0x7033)) {
kvmppc_mmu_book3s_64_init(vcpu);
@@ -762,14 +763,62 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu,
struct kvm_regs *regs)
int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
+ struct kvmppc_vcpu_book3s *vcpu3s = to_book3s(vcpu);
+ int i;
+
sregs-pvr = vcpu-arch.pvr;
+
+ sregs-u.s.sdr1 = to_book3s(vcpu)-sdr1;
+ if (vcpu-arch.hflags BOOK3S_HFLAG_SLB) {
+ for (i = 0; i 64; i++) {
+ sregs-u.s.ppc64.slb[i].slbe = vcpu3s-slb[i].orige | i;
+ sregs-u.s.ppc64.slb[i].slbv = vcpu3s-slb[i].origv;
+ }
+ } else {
+ for (i = 0; i 16; i++) {
+ sregs-u.s.ppc32.sr[i] = vcpu3s-sr[i].raw;
+ sregs-u.s.ppc32.sr[i] = vcpu3s-sr[i].raw;
+ }
+ for (i = 0; i 8; i++) {
+ sregs-u.s.ppc32.ibat[i] = vcpu3s-ibat[i].raw;
+ sregs-u.s.ppc32.dbat[i] = vcpu3s-dbat[i].raw;
+ }
+ }
return 0;
}
int
Re: [PATCH] PPC: Sync guest visible MMU state
On 11/30/2009 03:02 PM, Alexander Graf wrote: Currently userspace has no chance to find out which virtual address space we're in and resolve addresses. While that is a big problem for migration, it's also unpleasent when debugging, as gdb and the monitor don't work on virtual addresses. This patch exports enough of the MMU segment state to userspace to make debugging work and thus also includes the groundwork for migration. Looks good. Ben, please carry this in your tree. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] virtio-blk: add max sectors feature
On 11/25/2009 09:18 PM, Avishay Traeger1 wrote: This is a patch to have the guest virtio-blk driver get the value for the maximum I/O size from the host bdrv, rather than assume that there is no limit. Right now we use it for an in-house bdrv driver that needs this option. The patches are below, against the latest gits, split into kernel (kvm) and user-space (qemu-kvm) changes. I appreciate any comments. This should be started by a patch to http://ozlabs.org/~rusty/virtio-spec/. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2-repost] pcbios: enable io/memory unconditionally
On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote:
VGA adapters need to claim memory and i/o
transactions even if they do not have any
i/o or memory bars. E.g. PCI spec, page 297,
gives an example of such a device:
Programming interface b
VGA-compatible controller. Memory
addresses 0A h through 0B
h. I/O addresses 3B0h to 3BBh
and 3C0h to 3DFh and all aliases of
these addresses.
While we could check for these devices and special-case them, it is
easier to fix this by enabling i/o and memory space unconditionally:
devices that do not support it will just ignore this setting.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
This patch is needed for qemu-kvm as that is still using pcbios.
rombios32.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/rombios32.c b/rombios32.c
index 624f39f..d01b61d 100644
--- a/rombios32.c
+++ b/rombios32.c
@@ -693,6 +693,7 @@ void smp_probe(void)
#define PCI_COMMAND0x04/* 16 bits */
#define PCI_COMMAND_IO0x1 /* Enable response in I/O space
*/
#define PCI_COMMAND_MEMORY0x2 /* Enable response in Memory space */
+#define PCI_CLASS_PROG 0x09/* Reg. Level Programming Interface */
#define PCI_CLASS_DEVICE0x0a/* Device class */
#define PCI_INTERRUPT_LINE 0x3c/* 8 bits */
#define PCI_INTERRUPT_PIN 0x3d/* 8 bits */
@@ -760,7 +761,6 @@ static uint32_t pci_config_readb(PCIDevice *d, uint32_t
addr)
static void pci_set_io_region_addr(PCIDevice *d, int region_num, uint32_t addr)
{
-uint16_t cmd;
uint32_t ofs, old_addr;
if ( region_num == PCI_ROM_SLOT ) {
@@ -773,16 +773,6 @@ static void pci_set_io_region_addr(PCIDevice *d, int
region_num, uint32_t addr)
pci_config_writel(d, ofs, addr);
BX_INFO(region %d: 0x%08x\n, region_num, addr);
-
-/* enable memory mappings */
-cmd = pci_config_readw(d, PCI_COMMAND);
-if ( region_num == PCI_ROM_SLOT )
-cmd |= 2;
-else if (old_addr PCI_ADDRESS_SPACE_IO)
-cmd |= 1;
-else
-cmd |= 2;
-pci_config_writew(d, PCI_COMMAND, cmd);
}
/* return the global irq number corresponding to a given device irq
@@ -939,6 +929,7 @@ static void pci_bios_init_device(PCIDevice *d)
{
int class;
uint32_t *paddr;
+uint16_t cmd;
int i, pin, pic_irq, vendor_id, device_id;
class = pci_config_readw(d, PCI_CLASS_DEVICE);
@@ -1016,6 +1007,11 @@ static void pci_bios_init_device(PCIDevice *d)
break;
}
+/* enable memory mappings */
+cmd = pci_config_readw(d, PCI_COMMAND);
+cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
+pci_config_writew(d, PCI_COMMAND, cmd);
+
/* map the interrupt */
pin = pci_config_readb(d, PCI_INTERRUPT_PIN);
if (pin != 0) {
--
1.6.5.rc2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2-repost] pcbios: enable io/memory unconditionally
On Mon, Nov 30, 2009 at 04:17:22PM +0200, Michael S. Tsirkin wrote: On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote: VGA adapters need to claim memory and i/o transactions even if they do not have any i/o or memory bars. E.g. PCI spec, page 297, gives an example of such a device: Programming interface b VGA-compatible controller. Memory addresses 0A h through 0B h. I/O addresses 3B0h to 3BBh and 3C0h to 3DFh and all aliases of these addresses. While we could check for these devices and special-case them, it is easier to fix this by enabling i/o and memory space unconditionally: devices that do not support it will just ignore this setting. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- This patch is needed for qemu-kvm as that is still using pcbios. After applying it, f0c728d09728825f7f8b6896adcf6e4fd58dc7ef in qemu-kvm can be reverted. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Amount of virtual disks with KVM
Hi, Avi. On Monday, 30 November 2009 10:18:31 +0200, Avi Kivity wrote: I'm trying to make a migration of a Xen PV virtual machine to KVM. For this I'm starting a VM with SystemRescueCD [1] of the following way: # /usr/local/kvm/bin/qemu-system-x86_64 -hda /dev/vm/hermes-disk -boot d \ -cdrom /space/isos/systemrescuecd-x86-1.3.2.iso -m 512 -daemonize -vnc \ :2 -k es -localtime -hdb hermes-raiz.raw -hdc hermes-var.raw -net \ nic,vlan=0,macaddr=00:16:3e:00:00:34 -net tap Where hermes-disk is the disk that will use the VM in the destination host, and hermes-raiz.raw and hermes-var.raw are the raw partitions that was using the Xen PV virtual machine in source host. My idea is to create the partitions in hermes-disk, to mount the raw partitions and to do cp -a to the partitions created in hermes-disk, but after boot only hermes-disk and hermes-raiz.raw are exported (like sda and sdb). Which can be the problem? -cdrom and -hdc occupy the same IDE slot (second bus, master drive). Try -hdd instead of -hdc. Perfect! With -hdd and -cdrom, it exported the three disks and the ISO without problems. That would also explain why when not using -cdrom, the -hdc disk yes it is exported after to have installed with netinstall. Thanks for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Squeeze - Linux user #188.598 signature.asc Description: Digital signature
[PATCHv4-repost 0/2] qemu: cirrus reset-related fixes
These patches were part of series including BIOS fixes. BIOS fixes has been applied, but it looks like qemu fixes were forgotten. Reposting. Reset BARs and a couple of other registers on bus reset, as per PCI spec. Michael S. Tsirkin (2): qemu: make cirrus init value pci spec compliant qemu: cleanup unused macros in cirrus hw/cirrus_vga.c | 37 + 1 files changed, 1 insertions(+), 36 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4-repost 1/2] qemu: make cirrus init value pci spec compliant
PCI memory should be disabled at reset, otherwise we might claim transactions at address 0. I/O should also be disabled, although for cirrus it is harmless to enable it as we do not have I/O bar. Note: bios fix needed for this patch to work was already applied: previously bios incorrently assumed that it does not need to enable i/o unless device has i/o bar. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/cirrus_vga.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c index 9390d2c..89ffdf9 100644 --- a/hw/cirrus_vga.c +++ b/hw/cirrus_vga.c @@ -3249,7 +3249,6 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev) /* setup PCI */ pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_CIRRUS); pci_config_set_device_id(pci_conf, device_id); - pci_conf[0x04] = PCI_COMMAND_IOACCESS | PCI_COMMAND_MEMACCESS; pci_config_set_class(pci_conf, PCI_CLASS_DISPLAY_VGA); pci_conf[PCI_HEADER_TYPE] = PCI_HEADER_TYPE_NORMAL; -- 1.6.5.2.143.g8cc62 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4-repost 2/2] qemu: cleanup unused macros in cirrus
Cirrus vga has a copy of many PCI macros, and it doesn't even use them. Clean up. We also don't need to override header type as it is NORMAL by default. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/cirrus_vga.c | 36 +--- 1 files changed, 1 insertions(+), 35 deletions(-) diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c index 89ffdf9..edf0a8a 100644 --- a/hw/cirrus_vga.c +++ b/hw/cirrus_vga.c @@ -173,40 +173,6 @@ #define CIRRUS_MMIO_LINEDRAW_MODE 0x39 // byte #define CIRRUS_MMIO_BLTSTATUS 0x40 // byte -// PCI 0x04: command(word), 0x06(word): status -#define PCI_COMMAND_IOACCESS0x0001 -#define PCI_COMMAND_MEMACCESS 0x0002 -#define PCI_COMMAND_BUSMASTER 0x0004 -#define PCI_COMMAND_SPECIALCYCLE0x0008 -#define PCI_COMMAND_MEMWRITEINVALID 0x0010 -#define PCI_COMMAND_PALETTESNOOPING 0x0020 -#define PCI_COMMAND_PARITYDETECTION 0x0040 -#define PCI_COMMAND_ADDRESSDATASTEPPING 0x0080 -#define PCI_COMMAND_BACKTOBACKTRANS 0x0200 -// PCI 0x08, 0xff00 (0x09-0x0b:class,0x08:rev) -#define PCI_CLASS_BASE_DISPLAY0x03 -// PCI 0x08, 0x00ff -#define PCI_CLASS_SUB_VGA 0x00 -// PCI 0x0c, 0x00ff (0x0c:cacheline,0x0d:latency,0x0e:headertype,0x0f:Built-in self test) -// 0x10-0x3f (headertype 00h) -// PCI 0x10,0x14,0x18,0x1c,0x20,0x24: base address mapping registers -// 0x10: MEMBASE, 0x14: IOBASE(hard-coded in XFree86 3.x) -#define PCI_MAP_MEM 0x0 -#define PCI_MAP_IO 0x1 -#define PCI_MAP_MEM_ADDR_MASK (~0xf) -#define PCI_MAP_IO_ADDR_MASK(~0x3) -#define PCI_MAP_MEMFLAGS_32BIT 0x0 -#define PCI_MAP_MEMFLAGS_32BIT_1M 0x1 -#define PCI_MAP_MEMFLAGS_64BIT 0x4 -#define PCI_MAP_MEMFLAGS_CACHEABLE 0x8 -// PCI 0x28: cardbus CIS pointer -// PCI 0x2c: subsystem vendor id, 0x2e: subsystem id -// PCI 0x30: expansion ROM base address -#define PCI_ROMBIOS_ENABLED 0x1 -// PCI 0x34: 0xff00=reserved, 0x00ff=capabilities pointer -// PCI 0x38: reserved -// PCI 0x3c: 0x3c=int-line, 0x3d=int-pin, 0x3e=min-gnt, 0x3f=maax-lat - #define CIRRUS_PNPMMIO_SIZE 0x1000 #define ABS(a) ((signed)(a) 0 ? a : -a) @@ -3249,8 +3215,8 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev) /* setup PCI */ pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_CIRRUS); pci_config_set_device_id(pci_conf, device_id); + //pci_conf[0x04] = PCI_COMMAND_IOACCESS | PCI_COMMAND_MEMACCESS; pci_config_set_class(pci_conf, PCI_CLASS_DISPLAY_VGA); - pci_conf[PCI_HEADER_TYPE] = PCI_HEADER_TYPE_NORMAL; /* setup memory space */ /* memory #0 LFB */ -- 1.6.5.2.143.g8cc62 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2-repost] pcbios: enable io/memory unconditionally
Michael S. Tsirkin wrote: On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote: VGA adapters need to claim memory and i/o transactions even if they do not have any i/o or memory bars. E.g. PCI spec, page 297, gives an example of such a device: Programming interface b VGA-compatible controller. Memory addresses 0A h through 0B h. I/O addresses 3B0h to 3BBh and 3C0h to 3DFh and all aliases of these addresses. While we could check for these devices and special-case them, it is easier to fix this by enabling i/o and memory space unconditionally: devices that do not support it will just ignore this setting. Signed-off-by: Michael S. Tsirkin m...@redhat.com This is for stable? --- This patch is needed for qemu-kvm as that is still using pcbios. Why hasn't qemu-kvm switched to seabios? -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2-repost] pcbios: enable io/memory unconditionally
On 11/30/2009 06:00 PM, Anthony Liguori wrote: Michael S. Tsirkin wrote: On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote: VGA adapters need to claim memory and i/o transactions even if they do not have any i/o or memory bars. E.g. PCI spec, page 297, gives an example of such a device: Programming interface b VGA-compatible controller. Memory addresses 0A h through 0B h. I/O addresses 3B0h to 3BBh and 3C0h to 3DFh and all aliases of these addresses. While we could check for these devices and special-case them, it is easier to fix this by enabling i/o and memory space unconditionally: devices that do not support it will just ignore this setting. Signed-off-by: Michael S. Tsirkin m...@redhat.com This is for stable? This is for qemu-kvm.git to get pcbios consistent with seabios. --- This patch is needed for qemu-kvm as that is still using pcbios. Why hasn't qemu-kvm switched to seabios? Regressions. AFAICT all have been fixed now, and the switch is imminent. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2-repost] pcbios: enable io/memory unconditionally
On Mon, Nov 30, 2009 at 10:00:23AM -0600, Anthony Liguori wrote: Michael S. Tsirkin wrote: On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote: VGA adapters need to claim memory and i/o transactions even if they do not have any i/o or memory bars. E.g. PCI spec, page 297, gives an example of such a device: Programming interface b VGA-compatible controller. Memory addresses 0A h through 0B h. I/O addresses 3B0h to 3BBh and 3C0h to 3DFh and all aliases of these addresses. While we could check for these devices and special-case them, it is easier to fix this by enabling i/o and memory space unconditionally: devices that do not support it will just ignore this setting. Signed-off-by: Michael S. Tsirkin m...@redhat.com This is for stable? This is for qemu-kvm as the description says. --- This patch is needed for qemu-kvm as that is still using pcbios. Why hasn't qemu-kvm switched to seabios? IMO it's better to fix bug then switch than the reverse. This way you have a good base to compare against. -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix prefix register checking in arch/s390/kvm/sigp.c
This patch corrects the checking of the new address for the prefix register.
On s390, the prefix register is used to address the cpu's lowcore (address
0...8k). This check is supposed to verify that the memory is readable and
present.
copy_from_guest is a helper function, that can be used to read from guest
memory. It applies prefixing, adds the start address of the guest memory in
user, and then calls copy_from_user. Previous code was obviously broken for
two reasons:
- prefixing should not be applied here. The current prefix register is
going to be updated soon, and the address we're looking for will be
0..8k after we've updated the register
- we're adding the guest origin (gmsor) twice: once in subject code
and once in copy_from_guest
With kuli, we did not hit this problem because (a) we were lucky with
previous prefix register content, and (b) our guest memory was mmaped
very low into user address space.
This patch should go into 2.6.32, it prevents running smp guests with qemu.
Signed-off-by: Carsten Otte co...@de.ibm.com
Reported-by: Alexander Graf ag...@suse.de
---
sigp.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: kvm/arch/s390/kvm/sigp.c
===
--- kvm.orig/arch/s390/kvm/sigp.c 2009-10-13 11:09:04.0 +0200
+++ kvm/arch/s390/kvm/sigp.c2009-11-30 16:46:21.0 +0100
@@ -188,9 +188,9 @@
/* make sure that the new value is valid memory */
address = address 0x7fffe000u;
- if ((copy_from_guest(vcpu, tmp,
- (u64) (address + vcpu-arch.sie_block-gmsor) , 1)) ||
- (copy_from_guest(vcpu, tmp, (u64) (address +
+ if ((copy_from_user(tmp, (void __user *)
+ (address + vcpu-arch.sie_block-gmsor) , 1)) ||
+ (copy_from_user(tmp, (void __user *)(address +
vcpu-arch.sie_block-gmsor + PAGE_SIZE), 1))) {
*reg |= SIGP_STAT_INVALID_PARAMETER;
return 1; /* invalid parameter */
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/12] Maintain preemptability count even for !CONFIG_PREEMPT kernels
Ok so there is some variance in tests as usual due to cacheline placement. But it seems that overall we are looking at a 1-2% regression. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel bug in kvm_intel
On Sun, 2009-11-29 at 16:46 +0200, Avi Kivity wrote: On 11/26/2009 03:35 AM, Andrew Theurer wrote: I just tried testing tip of kvm.git, but unfortunately I think I might be hitting a different problem, where processes run 100% in kernel mode. In my case, cpus 9 and 13 were stuck, running qemu processes. A stack backtrace for both cpus are below. FWIW, kernel.org 2.6.32-rc7 does not have this problem, or the original problem. I just posted a patch fixing this, titled [PATCH tip:x86/entry] core: fix user return notifier on fork(). Thank you, Avi. I am running on this patch and am not seeing this problem anymore. I'll be testing for the previous issue next. -Andrew -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4-repost 2/2] qemu: cleanup unused macros in cirrus
Michael S. Tsirkin m...@redhat.com wrote: Cirrus vga has a copy of many PCI macros, and it doesn't even use them. Clean up. We also don't need to override header type as it is NORMAL by default. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/cirrus_vga.c | 36 +--- 1 files changed, 1 insertions(+), 35 deletions(-) diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c index 89ffdf9..edf0a8a 100644 --- a/hw/cirrus_vga.c +++ b/hw/cirrus_vga.c @@ -173,40 +173,6 @@ #define CIRRUS_MMIO_LINEDRAW_MODE 0x39 // byte #define CIRRUS_MMIO_BLTSTATUS 0x40 // byte -// PCI 0x04: command(word), 0x06(word): status -#define PCI_COMMAND_IOACCESS0x0001 -#define PCI_COMMAND_MEMACCESS 0x0002 -#define PCI_COMMAND_BUSMASTER 0x0004 -#define PCI_COMMAND_SPECIALCYCLE0x0008 -#define PCI_COMMAND_MEMWRITEINVALID 0x0010 -#define PCI_COMMAND_PALETTESNOOPING 0x0020 -#define PCI_COMMAND_PARITYDETECTION 0x0040 -#define PCI_COMMAND_ADDRESSDATASTEPPING 0x0080 -#define PCI_COMMAND_BACKTOBACKTRANS 0x0200 -// PCI 0x08, 0xff00 (0x09-0x0b:class,0x08:rev) -#define PCI_CLASS_BASE_DISPLAY0x03 -// PCI 0x08, 0x00ff -#define PCI_CLASS_SUB_VGA 0x00 -// PCI 0x0c, 0x00ff (0x0c:cacheline,0x0d:latency,0x0e:headertype,0x0f:Built-in self test) -// 0x10-0x3f (headertype 00h) -// PCI 0x10,0x14,0x18,0x1c,0x20,0x24: base address mapping registers -// 0x10: MEMBASE, 0x14: IOBASE(hard-coded in XFree86 3.x) -#define PCI_MAP_MEM 0x0 -#define PCI_MAP_IO 0x1 -#define PCI_MAP_MEM_ADDR_MASK (~0xf) -#define PCI_MAP_IO_ADDR_MASK(~0x3) -#define PCI_MAP_MEMFLAGS_32BIT 0x0 -#define PCI_MAP_MEMFLAGS_32BIT_1M 0x1 -#define PCI_MAP_MEMFLAGS_64BIT 0x4 -#define PCI_MAP_MEMFLAGS_CACHEABLE 0x8 -// PCI 0x28: cardbus CIS pointer -// PCI 0x2c: subsystem vendor id, 0x2e: subsystem id -// PCI 0x30: expansion ROM base address -#define PCI_ROMBIOS_ENABLED 0x1 -// PCI 0x34: 0xff00=reserved, 0x00ff=capabilities pointer -// PCI 0x38: reserved -// PCI 0x3c: 0x3c=int-line, 0x3d=int-pin, 0x3e=min-gnt, 0x3f=maax-lat - #define CIRRUS_PNPMMIO_SIZE 0x1000 #define ABS(a) ((signed)(a) 0 ? a : -a) @@ -3249,8 +3215,8 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev) /* setup PCI */ pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_CIRRUS); pci_config_set_device_id(pci_conf, device_id); + //pci_conf[0x04] = PCI_COMMAND_IOACCESS | PCI_COMMAND_MEMACCESS; You again added this here :) You agreed to remove this line that is a leftover of previous patch. pci_config_set_class(pci_conf, PCI_CLASS_DISPLAY_VGA); - pci_conf[PCI_HEADER_TYPE] = PCI_HEADER_TYPE_NORMAL; /* setup memory space */ /* memory #0 LFB */ for the rest, I agree with both patches. I trust you on pci defaults :) Later, Juan. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5-repost 0/2] qemu: cirrus reset-related fixes
These patches were part of series including BIOS fixes. BIOS fixes has been applied, but it looks like qemu fixes were forgotten. Reposting. Reset BARs and a couple of other registers on bus reset, as per PCI spec. This fixes up posting v4 which was garbled, sorry about that. Michael S. Tsirkin (2): qemu: make cirrus init value pci spec compliant qemu: cleanup unused macros in cirrus hw/cirrus_vga.c | 36 1 files changed, 0 insertions(+), 36 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5-repost 1/2] qemu: make cirrus init value pci spec compliant
PCI memory should be disabled at reset, otherwise we might claim transactions at address 0. I/O should also be disabled, although for cirrus it is harmless to enable it as we do not have I/O bar. Note: bios fix needed for this patch to work was already applied: previously bios incorrently assumed that it does not need to enable i/o unless device has i/o bar. Signed-off-by: Michael S. Tsirkin m...@redhat.com Acked-by: Juan Quintela quint...@redhat.com --- hw/cirrus_vga.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c index d76e5bb..e16026f 100644 --- a/hw/cirrus_vga.c +++ b/hw/cirrus_vga.c @@ -3231,7 +3231,6 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev) /* setup PCI */ pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_CIRRUS); pci_config_set_device_id(pci_conf, device_id); - pci_conf[0x04] = PCI_COMMAND_IOACCESS | PCI_COMMAND_MEMACCESS; pci_config_set_class(pci_conf, PCI_CLASS_DISPLAY_VGA); pci_conf[PCI_HEADER_TYPE] = PCI_HEADER_TYPE_NORMAL; -- 1.6.5.2.143.g8cc62 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5-repost 2/2] qemu: cleanup unused macros in cirrus
Cirrus vga has a copy of many PCI macros, and it doesn't even use them. Clean up. We also don't need to override header type as it is NORMAL by default. Signed-off-by: Michael S. Tsirkin m...@redhat.com Acked-by: Juan Quintela quint...@redhat.com --- hw/cirrus_vga.c | 35 --- 1 files changed, 0 insertions(+), 35 deletions(-) diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c index e16026f..8558212 100644 --- a/hw/cirrus_vga.c +++ b/hw/cirrus_vga.c @@ -172,40 +172,6 @@ #define CIRRUS_MMIO_LINEDRAW_MODE 0x39 // byte #define CIRRUS_MMIO_BLTSTATUS 0x40 // byte -// PCI 0x04: command(word), 0x06(word): status -#define PCI_COMMAND_IOACCESS0x0001 -#define PCI_COMMAND_MEMACCESS 0x0002 -#define PCI_COMMAND_BUSMASTER 0x0004 -#define PCI_COMMAND_SPECIALCYCLE0x0008 -#define PCI_COMMAND_MEMWRITEINVALID 0x0010 -#define PCI_COMMAND_PALETTESNOOPING 0x0020 -#define PCI_COMMAND_PARITYDETECTION 0x0040 -#define PCI_COMMAND_ADDRESSDATASTEPPING 0x0080 -#define PCI_COMMAND_BACKTOBACKTRANS 0x0200 -// PCI 0x08, 0xff00 (0x09-0x0b:class,0x08:rev) -#define PCI_CLASS_BASE_DISPLAY0x03 -// PCI 0x08, 0x00ff -#define PCI_CLASS_SUB_VGA 0x00 -// PCI 0x0c, 0x00ff (0x0c:cacheline,0x0d:latency,0x0e:headertype,0x0f:Built-in self test) -// 0x10-0x3f (headertype 00h) -// PCI 0x10,0x14,0x18,0x1c,0x20,0x24: base address mapping registers -// 0x10: MEMBASE, 0x14: IOBASE(hard-coded in XFree86 3.x) -#define PCI_MAP_MEM 0x0 -#define PCI_MAP_IO 0x1 -#define PCI_MAP_MEM_ADDR_MASK (~0xf) -#define PCI_MAP_IO_ADDR_MASK(~0x3) -#define PCI_MAP_MEMFLAGS_32BIT 0x0 -#define PCI_MAP_MEMFLAGS_32BIT_1M 0x1 -#define PCI_MAP_MEMFLAGS_64BIT 0x4 -#define PCI_MAP_MEMFLAGS_CACHEABLE 0x8 -// PCI 0x28: cardbus CIS pointer -// PCI 0x2c: subsystem vendor id, 0x2e: subsystem id -// PCI 0x30: expansion ROM base address -#define PCI_ROMBIOS_ENABLED 0x1 -// PCI 0x34: 0xff00=reserved, 0x00ff=capabilities pointer -// PCI 0x38: reserved -// PCI 0x3c: 0x3c=int-line, 0x3d=int-pin, 0x3e=min-gnt, 0x3f=maax-lat - #define CIRRUS_PNPMMIO_SIZE 0x1000 #define ABS(a) ((signed)(a) 0 ? a : -a) @@ -3232,7 +3198,6 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev) pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_CIRRUS); pci_config_set_device_id(pci_conf, device_id); pci_config_set_class(pci_conf, PCI_CLASS_DISPLAY_VGA); - pci_conf[PCI_HEADER_TYPE] = PCI_HEADER_TYPE_NORMAL; /* setup memory space */ /* memory #0 LFB */ -- 1.6.5.2.143.g8cc62 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM test: Add PCI device assignment support
Add support to PCI device assignment on the kvm test. It supports
both SR-IOV virtual functions and physical NIC card device
assignment.
Single Root I/O Virtualization (SR-IOV) allows a single PCI device to
be shared amongst multiple virtual machines while retaining the
performance benefit of assigning a PCI device to a virtual machine.
A common example is where a single SR-IOV capable NIC - with perhaps
only a single physical network port - might be shared with multiple
virtual machines by assigning a virtual function to each VM.
SR-IOV support is implemented in the kernel. The core implementation is
contained in the PCI subsystem, but there must also be driver support
for both the Physical Function (PF) and Virtual Function (VF) devices.
With an SR-IOV capable device one can allocate VFs from a PF. The VFs
surface as PCI devices which are backed on the physical PCI device by
resources (queues, and register sets).
Device support:
In 2.6.30, the Intel® 82576 Gigabit Ethernet Controller is the only
SR-IOV capable device supported. The igb driver has PF support and the
igbvf has VF support.
In 2.6.31 the Neterion® X3100™ is supported as well. This device uses
the same vxge driver for the PF as well as the VFs.
In order to configure the test:
* For SR-IOV virtual functions passthrough, we could specify the
module parameter 'max_vfs' in config file.
* For physical NIC card pass through, we should specify the device
name(s).
3rd try: The patch was heavily modified from the first 2 attempts:
* Naming is consistent with PCI assignment instead of
PCI passthrough, as it's a more correct term.
* No more device database file, as all information about devices
is stored on an attribute of the VM class (an instance of the
PciAssignable class), so we don't have to bother dumping this
info to a file.
* Code simplified to avoid duplication
As it's a fairly involved feature, the more reviews we get the better.
Signed-off-by: Yolkfull Chow yz...@redhat.com
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/tests/kvm/kvm_tests.cfg.sample | 20 +++-
client/tests/kvm/kvm_utils.py | 278 +
client/tests/kvm/kvm_vm.py| 59 +++
3 files changed, 356 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/kvm_tests.cfg.sample
b/client/tests/kvm/kvm_tests.cfg.sample
index feffb8d..be60399 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -844,13 +844,31 @@ variants:
only default
image_format = raw
-
variants:
- @smallpages:
- hugepages:
pre_command = /usr/bin/python scripts/hugepage.py /mnt/kvm_hugepage
extra_params += -mem-path /mnt/kvm_hugepage
+variants:
+- @no_pci_assignable:
+pci_assignable = no
+- pf_assignable:
+pci_assignable = pf
+device_names = eth1
+- vf_assignable:
+pci_assignable = vf
+# Driver (kernel module) that supports SR-IOV hardware.
+# As of today (30-11-2009), we have 2 drivers for this type of
hardware:
+# Intel® 82576 Gigabit Ethernet Controller - igb
+# Neterion® X3100™ - vxge
+driver = igb
+# Driver option to specify the number of virtual functions
+# (on vxge the option is , for example, is max_config_dev)
+# the default below is for the igb driver
+driver_option = max_vfs
+# Number of devices that are going to be requested.
+devices_requested = 7
variants:
- @basic:
diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
index bf25900..fc04745 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -874,3 +874,281 @@ def unmap_url_cache(cachedir, url, expected_hash,
method=md5):
file_path = utils.unmap_url(cachedir, src, cachedir)
return file_path
+
+
+def get_full_pci_id(pci_id):
+
+Get full PCI ID of pci_id.
+
+@param pci_id: PCI ID of a device.
+
+cmd = lspci -D | awk '/%s/ {print $1}' % pci_id
+status, full_id = commands.getstatusoutput(cmd)
+if status != 0:
+return None
+return full_id
+
+
+def get_vendor_from_pci_id(pci_id):
+
+Check out the device vendor ID according to pci_id.
+
+@param pci_id: PCI ID of a device.
+
+cmd = lspci -n | awk '/%s/ {print $3}' % pci_id
+return re.sub(:, , commands.getoutput(cmd))
+
+
+class PciAssignable(object):
+
+Request PCI assignable devices on host. It will check whether to request
+PF (physical Functions) or VF (Virtual Functions).
+
+def __init__(self, type=nic_vf, driver=None, driver_option=None,
+ names=None, devices_requested=None):
+
+Initialize parameter 'type' which could be:
+nic_vf: Virtual Functions
+nic_pf: Physical Function (actual hardware)
+mixed: Both includes VFs and PFs
+
+If pass
Re: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'
On 30 Nov 2009, Alejandro Riveira Fernández spake thusly: When I install the infamous nvidia driver I use. « sudo stop gdm » there are a start and restart aliases too see « man initctl ». Aha! That's done it. New upstartish aliases I hadn't noticed... FWIW, my qemu startup line (later adjusted, see below): DISPLAY=mutilate:0 /usr/bin/qemu-system-x86_64 -M pc-0.11 -enable-kvm -m 1024 \ -smp 2 -name ubuntwo -vnc :0 -boot c \ -drive file=/vm/linux/ubuntwo.img,if=virtio,index=0,boot=on,format=raw \ -drive file=/usr/local/tmp/ubuntu-9.10-beta-alternate-amd64.iso,if=ide,media=cdrom,index=2 \ -net nic,macaddr=52:54:00:4b:f7:7f,vlan=0,model=virtio,name=virtio.0 \ -net tap,vlan=0,ifname=ubuntwo,script=/sbin/qemu-linux.ifup,downscript=/sbin/qemu-linux.ifdown \ -parallel none -usb -k en-gb -vga vmware -soundhw ac97 -runas linux-vm \ -serial mon:telnet::10404,server,nowait Sometimes is not enough though and I have to stop gdm and then pkill the X server Unfortunately stopping X renders the vnc console useless. I got the SDL console working (note for frustrated others: a quick 'xhost +blah' no longer works in recent X versions, xhost support is gone from the server: you must propagate your xauth cookie across instead), whereupon it coredumps on me with a pretty-much-useless stacktrace: vmsvga_fifo_run (s=0x117e5e8) at /usr/src/qemu/x86_64-spindle/hw/vmware_vga.c:572 572 /usr/src/qemu/x86_64-spindle/hw/vmware_vga.c: No such file or directory. in /usr/src/qemu/x86_64-spindle/hw/vmware_vga.c (gdb) bt #0 vmsvga_fifo_run (s=0x117e5e8) at /usr/src/qemu/x86_64-spindle/hw/vmware_vga.c:572 #1 0x in ?? () I seem to be getting a lot of coredumps from qemu right now :( So I started with -vga std. The emulation failed flood is unaffected (strangely it's not consistent: it happens about half the time). As soon as I issue a 'stop gdm', X exits and the emulation flood halts: but although there are other getties running I can't find a way to switch to them, as qemu has stolen Ctrl-Alt for its own purposes: so the system is pretty much useless (maybe I should get an sshd up and try to restart things from there). (I've never needed to do this before: either my qemus have been text mode all the time, or X with one console.) Surely switching VTs is possible: any clues? Unfortunately Ubuntu bug 417859 has broken the recovery console so I can't use that to get me in in text mode and *then* start X. Not fixed, but then it's only a bug in something critical to system recovery which has been open for months and has had variations on the same bug open for *two flipping years*. Sheesh. :/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: Fix assigned device config space
On Fri, Nov 27, 2009 at 10:41:05AM +0800, Sheng Yang wrote: The new pci_dev-dev.config is a uint_8 pointer, but get_real_device() still using sizeof(pci_dev-dev.config) to fill the configuration space, which lost most of information. Spot the issue when INTx cannot work again after previous fix... Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Disable unrestricted guest when EPT disabled
On Fri, Nov 27, 2009 at 04:46:26PM +0800, Sheng Yang wrote: Otherwise would cause VMEntry failure when using ept=0 on unrestricted guest supported processors. Signed-off-by: Sheng Yang sh...@linux.intel.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5-repost 0/2] qemu: cirrus reset-related fixes
Michael S. Tsirkin m...@redhat.com wrote: These patches were part of series including BIOS fixes. BIOS fixes has been applied, but it looks like qemu fixes were forgotten. Reposting. Reset BARs and a couple of other registers on bus reset, as per PCI spec. This fixes up posting v4 which was garbled, sorry about that. Michael S. Tsirkin (2): qemu: make cirrus init value pci spec compliant qemu: cleanup unused macros in cirrus hw/cirrus_vga.c | 36 1 files changed, 0 insertions(+), 36 deletions(-) Acked-by: Juan Quintela quint...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] virtio: set pci bus master enable bit
On Mon, 30 Nov 2009 02:22:01 am Michael S. Tsirkin wrote: As all virtio devices perform DMA, we must enable bus mastering for them to be spec compliant. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/virtio/virtio_pci.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index 28d9cf7..717bae1 100644 --- a/drivers/virtio/virtio_pci.c +++ b/drivers/virtio/virtio_pci.c @@ -648,6 +648,7 @@ static int __devinit virtio_pci_probe(struct pci_dev *pci_dev, goto out_req_regions; pci_set_drvdata(pci_dev, vp_dev); + pci_set_master(pci_dev); I can believe this, but I have no idea if it's right. I've applied it, and hope Jesse will comment if there's something wrong with it. Thanks, Rusty. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM test: Add PCI device assignment support
On Mon, Nov 30, 2009 at 07:08:11PM -0200, Lucas Meneghel Rodrigues wrote:
Add support to PCI device assignment on the kvm test. It supports
both SR-IOV virtual functions and physical NIC card device
assignment.
Single Root I/O Virtualization (SR-IOV) allows a single PCI device to
be shared amongst multiple virtual machines while retaining the
performance benefit of assigning a PCI device to a virtual machine.
A common example is where a single SR-IOV capable NIC - with perhaps
only a single physical network port - might be shared with multiple
virtual machines by assigning a virtual function to each VM.
SR-IOV support is implemented in the kernel. The core implementation is
contained in the PCI subsystem, but there must also be driver support
for both the Physical Function (PF) and Virtual Function (VF) devices.
With an SR-IOV capable device one can allocate VFs from a PF. The VFs
surface as PCI devices which are backed on the physical PCI device by
resources (queues, and register sets).
Device support:
In 2.6.30, the Intel® 82576 Gigabit Ethernet Controller is the only
SR-IOV capable device supported. The igb driver has PF support and the
igbvf has VF support.
In 2.6.31 the Neterion® X3100™ is supported as well. This device uses
the same vxge driver for the PF as well as the VFs.
In order to configure the test:
* For SR-IOV virtual functions passthrough, we could specify the
module parameter 'max_vfs' in config file.
* For physical NIC card pass through, we should specify the device
name(s).
3rd try: The patch was heavily modified from the first 2 attempts:
* Naming is consistent with PCI assignment instead of
PCI passthrough, as it's a more correct term.
* No more device database file, as all information about devices
is stored on an attribute of the VM class (an instance of the
PciAssignable class), so we don't have to bother dumping this
info to a file.
* Code simplified to avoid duplication
As it's a fairly involved feature, the more reviews we get the better.
Hi Lucas,
I have some ideas about devices_requested parameter, please see comments
below:
Signed-off-by: Yolkfull Chow yz...@redhat.com
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/tests/kvm/kvm_tests.cfg.sample | 20 +++-
client/tests/kvm/kvm_utils.py | 278
+
client/tests/kvm/kvm_vm.py| 59 +++
3 files changed, 356 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/kvm_tests.cfg.sample
b/client/tests/kvm/kvm_tests.cfg.sample
index feffb8d..be60399 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -844,13 +844,31 @@ variants:
only default
image_format = raw
-
variants:
- @smallpages:
- hugepages:
pre_command = /usr/bin/python scripts/hugepage.py /mnt/kvm_hugepage
extra_params += -mem-path /mnt/kvm_hugepage
+variants:
+- @no_pci_assignable:
+pci_assignable = no
+- pf_assignable:
+pci_assignable = pf
+device_names = eth1
+- vf_assignable:
+pci_assignable = vf
+# Driver (kernel module) that supports SR-IOV hardware.
+# As of today (30-11-2009), we have 2 drivers for this type of
hardware:
+# Intel® 82576 Gigabit Ethernet Controller - igb
+# Neterion® X3100™ - vxge
+driver = igb
+# Driver option to specify the number of virtual functions
+# (on vxge the option is , for example, is max_config_dev)
+# the default below is for the igb driver
+driver_option = max_vfs
+# Number of devices that are going to be requested.
+devices_requested = 7
I think we'd better specify not only number of driver_option 'max_vfs' but
also devices_requested. Reasons:
1) The value of driver option 'max_vfs' is different with devices_requested.
Typically, if we assign 7 to max_vfs, it will virtualize 14(7*2) VFs.
2) Also, we can later write a case that boots 14 VMs and assign one Virtual
Function to each of them. Thus we need to modprobe max_vfs=7, and set
devices_requested=1. It could be boundary test, already a bug exists.
What do you think?
variants:
- @basic:
diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
index bf25900..fc04745 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -874,3 +874,281 @@ def unmap_url_cache(cachedir, url, expected_hash,
method=md5):
file_path = utils.unmap_url(cachedir, src, cachedir)
return file_path
+
+
+def get_full_pci_id(pci_id):
+
+Get full PCI ID of pci_id.
+
+@param pci_id: PCI ID of a device.
+
+cmd = lspci -D | awk '/%s/ {print $1}' % pci_id
+status, full_id = commands.getstatusoutput(cmd)
+if status != 0:
+return None
+
[PATCH] KVM test: Test 802.1Q vlan of nic
Test 802.1Q vlan of nic, config it by vconfig command. 1) Create two VMs 2) Setup guests in different vlan by vconfig and test communication by ping using hard-coded ip address 3) Setup guests in same vlan and test communication by ping 4) Recover the vlan config The subnet of vlan can be setup in configure file. 3rd try: * Instead of using lists of vms and sessions, just use vm1 and vm2 and session1 and session2 as it's clearer and we just need 2 vms. Signed-off-by: Amos Kong ak...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample | 13 ++- client/tests/kvm/tests/vlan_tag.py| 67 + 2 files changed, 79 insertions(+), 1 deletions(-) create mode 100644 client/tests/kvm/tests/vlan_tag.py diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index feffb8d..5e15b30 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -243,6 +243,17 @@ variants: kill_vm = yes kill_vm_gracefully = no +- vlan_tag: install setup unattended_install +type = vlan_tag +# subnet should not be used by host +subnet = 192.168.123 +vlans = 10 20 +nic_mode = tap +vms += vm2 +extra_params_vm1 += -snapshot +extra_params_vm2 += -snapshot +kill_vm_gracefully_vm2 = no +address_index_vm2 = 1 # NICs variants: @@ -525,7 +536,7 @@ variants: unattended_file = unattended/RHEL-3-series.ks # Windows section - @Windows: -no autotest linux_s3 +no autotest linux_s3 vlan_tag shutdown_command = shutdown /s /t 0 reboot_command = shutdown /r /t 0 status_test_command = echo %errorlevel% diff --git a/client/tests/kvm/tests/vlan_tag.py b/client/tests/kvm/tests/vlan_tag.py new file mode 100644 index 000..88baf23 --- /dev/null +++ b/client/tests/kvm/tests/vlan_tag.py @@ -0,0 +1,67 @@ +import logging, time +from autotest_lib.client.common_lib import error +import kvm_subprocess, kvm_test_utils, kvm_utils + + +def run_vlan_tag(test, params, env): + +Test 802.1Q vlan of NIC, config it by vconfig command. + +1) Create two VMs. +2) Setup guests in different VLANs by vconfig and test communication by + ping using hard-coded ip addresses. +3) Setup guests in same vlan and test communication by ping. +4) Recover the vlan config. + +@param test: KVM test object. +@param params: Dictionary with the test parameters. +@param env: Dictionary with test environment. + +subnet = params.get(subnet) +vlans = params.get(vlans).split() + +vm1 = kvm_test_utils.get_living_vm(env, params.get(main_vm)) +vm2 = kvm_test_utils.get_living_vm(env, vm2) + +session1 = kvm_test_utils.wait_for_login(vm1) +session2 = kvm_test_utils.wait_for_login(vm2) + +try: +ip_cfg_base = vconfig add eth0 %s ifconfig eth0.%s %s.%s +ip_cfg_cmd1 = ip_cfg_base % (vlans[0], vlans[0], subnet, 11) +ip_cfg_cmd2 = ip_cfg_base % (vlans[1], vlans[1], subnet, 12) + +# Configure VM1 and VM2 in different VLANs +ip_cfg_vm1 = session1.get_command_status(ip_cfg_cmd1) +if ip_cfg_vm1 != 0: +raise error.TestError(Failed to config VM 1 IP address) +ip_cfg_vm2 = session2.get_command_status(ip_cfg_cmd2) +if ip_cfg_vm2 != 0: +raise error.TestError(Failed to config VM 2 IP address) + +# Trying to ping VM 2 from VM 1, this shouldn't work +ping_cmd = ping -c 2 -I eth0.%s %s.%s % (vlans[0], subnet, 12) +ping_diff_vlan = session1.get_command_status(ping_cmd) +if ping_diff_vlan == 0: +raise error.TestFail(VM 2 can be reached even though it was + configured on a different VLAN) + +# Now let's put VM 2 in the same VLAN as VM 1 +ip_cfg_reconfig= (vconfig rem eth0.%s vconfig add eth0 %s + ifconfig eth0.%s %s.%s % (vlans[1], vlans[0], + vlans[0], subnet, 12)) +ip_cfg_vm2 = session2.get_command_status(ip_cfg_reconfig) +if ip_cfg_vm2 != 0: +raise error.TestError(Failed to re-config IP address of VM 2) + +# Try to ping VM 2 from VM 1, this should work +ping_same_vlan = session1.get_command_status(ping_cmd) +if ping_same_vlan != 0: +raise error.TestFail(Failed to ping VM 2 even though it was + configured on the same VLAN) + +finally: +session1.get_command_status(vconfig rem eth0.%s % vlans[0]) +session1.close() +session2.get_command_status(vconfig rem eth0.%s % vlans[0]) +session2.close() -- 1.6.5.2 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PATCH] KVM: Drop user return notifier when disabling virtualization on a cpu
On Sat, Nov 28, 2009 at 02:18:47PM +0200, Avi Kivity wrote: This way, we don't leave a dangling notifier on cpu hotunplug or module unload. In particular, module unload leaves the notifier pointing into freed memory. Signed-off-by: Avi Kivity a...@redhat.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
About implementation of KVM server-side migration in autotest
Hi Michael and Lucas,
Would you please give me some comments/suggestions based on
my initial design of it? Thanks in advance. :)
KVM server-side migration design =
1 for generating migration test dicts, two methods:
1.1 use existent framework of kvm client test
1.2 new a script named kvm_migration.py under dir kvm, initial version could be:
kvm_migration.py
import sys, os, time, logging, commands
from autotest_lib.client.bin import test
from autotest_lib.client.common_lib import error
import kvm_utils, kvm_preprocessing, common, kvm_vm, kvm_test_utils
class kvm_migration(test.test):
KVM migration test.
@copyright: Red Hat 2008-2009
@see: http://www.linux-kvm.org/page/KVM-Autotest/Client_Install
(Online doc - Getting started with KVM testing)
version = 1
def initialize(self):
pass
def setup(self):
Setup environment like NFS mount etc.
pass
def run_once(self, params):
Setup remote machine and then execute migration.
# Check whether remote machine is ready
dsthost = params.get(dsthost)
srchost = params.get(srchost)
image_path = os.path.join(self.bindir, images)
rootdir = params.get(rootdir)
iso = os.path.join(rootdir, 'iso')
images = os.path.join(rootdir, 'images')
qemu = os.path.join(rootdir, 'qemu')
qemu_img = os.path.join(rootdir, 'qemu-img')
def link_if_not_exist(ldir, target, link_name):
t = target
l = os.path.join(ldir, link_name)
if not os.path.exists(l):
os.symlink(t,l)
link_if_not_exist(self.bindir, '../../', 'autotest')
link_if_not_exist(self.bindir, iso, 'isos')
link_if_not_exist(self.bindir, images, 'images')
link_if_not_exist(self.bindir, qemu, 'qemu')
link_if_not_exist(self.bindir, qemu_img, 'qemu-img')
try:
image_real_path = os.readlink(image_path)
except OSError:
raise error.TestError(Readlink of image dir failed)
def setup_dest(srchost, path):
Mount NFS directory from source host.
cmd = mount |grep -q %s % srchost
if os.system(cmd):
mnt_cmd = mount %s:%s %s % (srchost,
path,
path)
s, o = commands.getstatusoutput(mnt_cmd)
if s != 0:
raise error.TestError(Mount srchost failed: %s % o)
def setup_source(path):
Setup NFS mount point.
export_string = %s *(rw,no_root_squash) % path
export_file = '/etc/exports'
f = open(export_file)
if not export_string in f.read().strip():
try:
f.write(export_string)
except IOError:
raise error.TestError(Failed to write to exports file)
cmd = service nfs restart exportfs -a
if os.system(cmd):
raise error.TestError(Failed to restart NFS on source)
if params.get(role) == dest:
setup_dest(srchost, image_real_path)
elif params.get(role) == source:
setup_source(image_real_path)
# Report the parameters we've received and write them as keyvals
logging.debug(Test parameters:)
keys = params.keys()
keys.sort()
for key in keys:
logging.debug(%s = %s, key, params[key])
self.write_test_keyval({key: params[key]})
# Open the environment file
env_filename = os.path.join(self.bindir, params.get(env, env))
env = kvm_utils.load_env(env_filename, {})
logging.debug(Contents of environment: %s % str(env))
# Preprocess
kvm_preprocessing.preprocess(self, params, env)
kvm_utils.dump_env(env, env_filename)
try:
try:
# Get the living VM
vm = kvm_test_utils.get_living_vm(env, params.get(main_vm))
if params.get(role) == source:
s, o = vm.send_monitor_cmd(help info)
if not info migrate in o:
raise error.TestError(Migration is not supported)
session = kvm_test_utils.wait_for_login(vm)
migration_test_command =
params.get(migration_test_command)
reference_output =
session.get_command_output(migration_test_command)
kvm_test_utils.migrate(vm, dsthost, vm.migration_port, env)
session.close()
elif params.get(role) == dest:
try:
mig_timeout = int(params.get(mig_timeout))
session =
[KVM-AUTOTEST PATCH] Improve kvm subtest AutoIt - add option to download script from remote server
Add an option to let user download the .au3 script from a remote server, and keep the original method to prepare the script. This makes it possible to employ AutoIt tests that involve several files. new variants: 1. download, if params.get(download) == yes, download the scripts to guest, else use the original method, echo the code into guest. 2. download_cmd, What tool to use to download. User can choose git, as in the sample file, svn, ftp, or wget, or other preferred tools. NOTE, this requires that the download tool is installed in the guest, or the tools have been placed in winutils.iso. 3. rsc_server, Resource server which contains the AutoIt script and provide a download service. 4. dst_rsc_dir, Destination of the AutoIt scripts in the guest. i.e. the downloaded resource will be saved in this default dir. 5. autoit_entry, Which .au3 file to start to run. this will be useful if a test involves several .au3 files. Signed-off-by: Cao, Chen k...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample |6 client/tests/kvm/tests/autoit.py | 45 ++-- 2 files changed, 37 insertions(+), 14 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 5e15b30..f688b97 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -169,6 +169,12 @@ variants: variants: - notepad: autoit_script = autoit/notepad1.au3 +- stub: +download = yes +download_cmd = git clone +rsc_server = git://the.resource.server/autoit +dst_rsc_dir = C:\ +autoit_entry = C:\autoit\stub\stub.au3 - guest_s4: install setup unattended_install type = guest_s4 diff --git a/client/tests/kvm/tests/autoit.py b/client/tests/kvm/tests/autoit.py index 9435d7c..ed1d491 100644 --- a/client/tests/kvm/tests/autoit.py +++ b/client/tests/kvm/tests/autoit.py @@ -25,23 +25,40 @@ def run_autoit(test, params, env): # Collect test parameters binary = params.get(autoit_binary) script = params.get(autoit_script) +autoit_entry = params.get(autoit_entry, script.au3) script_params = params.get(autoit_script_params, ) timeout = float(params.get(autoit_script_timeout, 600)) -# Send AutoIt script to guest (this code will be replaced once we -# support sending files to Windows guests) -session.get_command_output(del script.au3, internal_timeout=0) -file = open(kvm_utils.get_path(test.bindir, script)) -for line in file.readlines(): -# Insert a '^' before each character -line = .join(^ + c for c in line.rstrip()) -if line: -# Append line to the file -session.get_command_output(echo %sscript.au3 % line, - internal_timeout=0) -file.close() - -command = cmd /c %s script.au3 %s % (binary, script_params) +# Download the script resource from a remote server, or +# prepare the script using rss? +if params.get(download) == yes: +download_cmd = params.get(download_cmd) +rsc_server = params.get(rsc_server) +dst_rsc_dir = params.get(dst_rsc_dir) + +# Change dir to dst_rsc_dir, and remove 'autoit' there, then +# download the resource. +rsc_cmd = cd %s (rmdir /s /q autoit || del /s /q autoit) \ + %s %s % (dst_rsc_dir, download_cmd, rsc_server) + +if session.get_command_status(rsc_cmd, timeout=timeout) != 0: +raise error.TestFail(Download test resource failed.) +logging.info(Download resource finished.) +else: +# Send AutoIt script to guest (this code will be replaced once we +# support sending files to Windows guests) +session.get_command_output(del script.au3, internal_timeout=0) +file = open(kvm_utils.get_path(test.bindir, script)) +for line in file.readlines(): +# Insert a '^' before each character +line = .join(^ + c for c in line.rstrip()) +if line: +# Append line to the file +session.get_command_output(echo %sscript.au3 % line, + internal_timeout=0) +file.close() + +command = cmd /c %s %s %s % (binary, autoit_entry, script_params) logging.info( Script output ) status = session.get_command_status(command, -- 1.5.5.6 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Direct access to GPGPU do-able?
Hi, I'll start with a one-off question here, so please cc me on the reply. We are running a largish cluster and are currently buying GPGPU systems (Tesla and soon Fermi based). We will have at least 2 possibly 4 of these cards per box and have the problem that some codes need different CUDA kernel drivers to run. As these boxes have 4 CPU cores, 12 GB of memory and CPU-VT support we thought that this might be solvable by creating (para-) virtualized guests on the boxes and passing one GPGPU device into a guest at a time. In there we then can run any kernel/driver combo necessary. But since my current virtualization experience only stretches to OpenVZ and VirtualBox (tinkering with Xen a couple of years back), I don't know if KVM is the right approach here. We need something which we can automatically set-up via CLI, i.e. starting and stopping the guests need to be fully automatic, we don't need a graphical environment within the guests, just plain text is good enough. What do you think, is looking at KVM the right choice for this? Can we pass a device directly into a guest? Cheers Carsten -- Dr. Carsten Aulbert - Max Planck Institute for Gravitational Physics Callinstrasse 38, 30167 Hannover, Germany Phone/Fax: +49 511 762-17185 / -17193 http://www.top500.org/system/9234 | http://www.top500.org/connfam/6/list/3 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: guest gets stuck on the migration from AMD to Intel
Avi Kivity wrote: Hm, pvmmu. Can you provide /proc/cpuinfo on the source (AMD) host? Sure: % cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : Dual-Core AMD Opteron(tm) Processor 1210 stepping: 2 cpu MHz : 1795.804 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 3591.60 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : Dual-Core AMD Opteron(tm) Processor 1210 stepping: 2 cpu MHz : 1795.804 cache size : 1024 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 3591.17 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc Hope this helps. Please mail. Regards Harri -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH] Improve kvm subtest AutoIt - add option to download script from remote server
- Chen Cao k...@redhat.com wrote: Add an option to let user download the .au3 script from a remote server, and keep the original method to prepare the script. This makes it possible to employ AutoIt tests that involve several files. new variants: 1. download, if params.get(download) == yes, download the scripts to guest, else use the original method, echo the code into guest. 2. download_cmd, What tool to use to download. User can choose git, as in the sample file, svn, ftp, or wget, or other preferred tools. NOTE, this requires that the download tool is installed in the guest, or the tools have been placed in winutils.iso. 3. rsc_server, Resource server which contains the AutoIt script and provide a download service. 4. dst_rsc_dir, Destination of the AutoIt scripts in the guest. i.e. the downloaded resource will be saved in this default dir. 5. autoit_entry, Which .au3 file to start to run. this will be useful if a test involves several .au3 files. Signed-off-by: Cao, Chen k...@redhat.com I haven't reviewed the code yet, but I have 2 quick questions: - If the files we'll be downloading are text files (.au3 files), then why not download them in the host and send them to the guest using the echo method? This imposes less requirements on the guest. - Why not add the ability to send multiple files from the host to the guest, using the echo method, without downloading them? BTW, this echo method is meant to be used only until we add file transfer support to rss.exe (I'm not sure when exactly that will happen). --- client/tests/kvm/kvm_tests.cfg.sample |6 client/tests/kvm/tests/autoit.py | 45 ++-- 2 files changed, 37 insertions(+), 14 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 5e15b30..f688b97 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -169,6 +169,12 @@ variants: variants: - notepad: autoit_script = autoit/notepad1.au3 +- stub: +download = yes +download_cmd = git clone +rsc_server = git://the.resource.server/autoit +dst_rsc_dir = C:\ +autoit_entry = C:\autoit\stub\stub.au3 - guest_s4: install setup unattended_install type = guest_s4 diff --git a/client/tests/kvm/tests/autoit.py b/client/tests/kvm/tests/autoit.py index 9435d7c..ed1d491 100644 --- a/client/tests/kvm/tests/autoit.py +++ b/client/tests/kvm/tests/autoit.py @@ -25,23 +25,40 @@ def run_autoit(test, params, env): # Collect test parameters binary = params.get(autoit_binary) script = params.get(autoit_script) +autoit_entry = params.get(autoit_entry, script.au3) script_params = params.get(autoit_script_params, ) timeout = float(params.get(autoit_script_timeout, 600)) -# Send AutoIt script to guest (this code will be replaced once we -# support sending files to Windows guests) -session.get_command_output(del script.au3, internal_timeout=0) -file = open(kvm_utils.get_path(test.bindir, script)) -for line in file.readlines(): -# Insert a '^' before each character -line = .join(^ + c for c in line.rstrip()) -if line: -# Append line to the file -session.get_command_output(echo %sscript.au3 % line, - internal_timeout=0) -file.close() - -command = cmd /c %s script.au3 %s % (binary, script_params) +# Download the script resource from a remote server, or +# prepare the script using rss? +if params.get(download) == yes: +download_cmd = params.get(download_cmd) +rsc_server = params.get(rsc_server) +dst_rsc_dir = params.get(dst_rsc_dir) + +# Change dir to dst_rsc_dir, and remove 'autoit' there, then +# download the resource. +rsc_cmd = cd %s (rmdir /s /q autoit || del /s /q autoit) \ + %s %s % (dst_rsc_dir, download_cmd, rsc_server) + +if session.get_command_status(rsc_cmd, timeout=timeout) != 0: +raise error.TestFail(Download test resource failed.) +logging.info(Download resource finished.) +else: +# Send AutoIt script to guest (this code will be replaced once we +# support sending files to Windows guests) +session.get_command_output(del script.au3, internal_timeout=0) +file = open(kvm_utils.get_path(test.bindir, script)) +for line in file.readlines(): +# Insert a '^' before each character +line = .join(^ + c for c
