Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Monday 05 May 2008 06:10:08 pm Guillaume Thouvenin wrote: On Sat, 3 May 2008 13:56:56 +0530 Balaji Rao [EMAIL PROTECTED] wrote: With your patch applied ubuntu 8.04 livecd fails to boot. Not any better with Marcelo's patch on top. Hi Balaji, And without the patch, can you boot the ubuntu 8.04 livecd? Yes, I can. :) Regards, Guillaume -- Warm Regards, Balaji Rao Dept. of Mechanical Engineering NITK - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Friday 02 May 2008 12:43:31 am Marcelo Tosatti wrote: Hi Guillaume, With your patch applied ubuntu 8.04 livecd fails to boot. Not any better with Marcelo's patch on top. exception 13 (33) rax 007f rbx 0080 rcx rdx rsi 0005a81c rdi 0005a820 rsp fffa97cc rbp 200c r8 r9 r10 r11 r12 r13 r14 r15 rip b02c rflags 00033882 cs 4004 (00040040/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 4004 (00040040/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 5881 (00058810/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 3002 (00030020/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (fffbd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 40920/47 idt 0/ cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 10 28 6d 01 28 1e 01 28 6d 01 28 1f 01 28 6d 01 28 73 01 17 -- 0f 28 6d 01 28 74 01 17 0f 17 3b 28 6d 01 28 75 01 17 0f 28 6d 01 28 76 01 17 0f 11 1c 17 Aborted -- Warm Regards, Balaji Rao Dept. of Mechanical Engineering NITK - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kernel BUG at drivers/virtio/virtio_ring.c:218!
On Sunday 06 April 2008 12:56:33 pm Rusty Russell wrote:
On Sunday 06 April 2008 00:53:39 Balaji Rao wrote:
On Friday 04 April 2008 01:46:21 pm Balaji Rao wrote:
Hi Rusty,
I hit a bug in virtio_ring.c:218 when I was stressing virtio_net using
kvm with -smp 4.
static void vring_disable_cb(struct virtqueue *_vq)
{
struct vring_virtqueue *vq = to_vvq(_vq);
START_USE(vq);
--BUG_ON(vq-vring.avail-flags VRING_AVAIL_F_NO_INTERRUPT);
vq-vring.avail-flags |= VRING_AVAIL_F_NO_INTERRUPT;
END_USE(vq);
}
Going through the source code, I felt that this BUG_ON is not required as
any CPU could race and call disable_cb when one cpu still believes that
its enabled. To validate my understanding, I commented out the BUG_ON and
everything worked perfectly well.
I also get a lot of Unlikely: restart svq race on my console. Under
high load conditions, a race could occur very often and I'm not sure if
that signals a buggy situation. We could printk_ratelimit if at all we
need to retain it.
If you agree, I'll send a patch to this.
Christian Borntraeger CCed.
Hi Balaji,
Interesting case can you put a '#define DEBUG' at the top of
drivers/virtio/virtio_ring.c and re-run?
The reason we don't simply remove that check is that interrupt bugs are nasty
to track down, usually leading to performance problems rather than outright
breakage.
Hi Rusty,
Here's the output with #define DEBUG. As soon as I start netperf on the remote
machine, the guest panics.
sh-3.2# [ 40.053295] Unlikely: restart svq race
[ 39.999687] Unlikely: restart svq race
[ 40.000687] [ cut here ]
[ 40.001885] kernel BUG at drivers/virtio/virtio_ring.c:219!
[ 40.003401] invalid opcode: [#1] SMP DEBUG_PAGEALLOC
[ 40.003670] Modules linked in:
[ 40.003670]
[ 40.003670] Pid: 1553, comm: netserver Not tainted (2.6.25-rc7 #19)
[ 40.003670] EIP: 0060:[c03a4c22] EFLAGS: 00010202 CPU: 3
[ 40.003670] EIP is at vring_disable_cb+0x2c/0x4e
[ 40.003670] EAX: f7570430 EBX: c0616a64 ECX: f74e8800 EDX: 0001
[ 40.003670] ESI: f6c45000 EDI: f75d8c80 EBP: f6c879e0 ESP: f6c879e0
[ 40.003670] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 40.003670] Process netserver (pid: 1553, ti=f6c86000 task=f6cf
task.ti=f6c86000)
[ 40.003670] Stack: f6c87b94 c0319cde c059fe55 f75d8840 0002 c16da8a2
0020 000a
[ 40.003670] c16fb8a2 0b8e 0042
[ 40.003670]
[ 40.003670] Call Trace:
[ 40.003670] [c0319cde] ? start_xmit+0x1c6/0x209
[ 40.003670] [c0434104] ? ipt_route_hook+0x18/0x1d
[ 40.003670] [c03e8a7f] ? dev_hard_start_xmit+0x204/0x272
[ 40.003670] [c04086b2] ? ip_finish_output+0x0/0x201
[ 40.003670] [c03f77cb] ? __qdisc_run+0x78/0x15a
[ 40.003670] [c03ead5f] ? dev_queue_xmit+0x17e/0x28b
[ 40.003670] [c040887b] ? ip_finish_output+0x1c9/0x201
[ 40.003670] [c0408b50] ? ip_output+0x7e/0x83
[ 40.003670] [c04083eb] ? ip_local_out+0x18/0x1b
[ 40.003670] [c0408e5d] ? ip_queue_xmit+0x278/0x2b9
[ 40.003670] [c01729d6] ? check_object+0x139/0x18f
[ 40.003670] [c017351b] ? __slab_alloc+0x3d7/0x467
[ 40.003670] [c041af67] ? tcp_v4_send_check+0x7d/0xb7
[ 40.003670] [c0416d9d] ? tcp_transmit_skb+0x618/0x64b
[ 40.003670] [c01741ed] ? __kmalloc_track_caller+0x7d/0xcb
[ 40.003670] [c0416e69] ? tcp_send_ack+0x25/0xb6
[ 40.003670] [c03e43db] ? __alloc_skb+0x4f/0xfd
[ 40.003670] [c0416ef2] ? tcp_send_ack+0xae/0xb6
[ 40.003670] [c0414a11] ? __tcp_ack_snd_check+0x5e/0x73
[ 40.003670] [c0415f1b] ? tcp_rcv_established+0x5f1/0x652
[ 40.003670] [c0478e85] ? _spin_lock_bh+0xb/0x22
[ 40.003670] [c041a973] ? tcp_v4_do_rcv+0x28/0x18d
[ 40.003670] [c040d2b6] ? tcp_prequeue_process+0x52/0x66
[ 40.003670] [c040f236] ? tcp_recvmsg+0x32a/0x6af
[ 40.003670] [c03e0667] ? sock_common_recvmsg+0x31/0x4a
[ 40.003670] [c03df11d] ? sock_recvmsg+0xe9/0x105
[ 40.003670] [c01181c0] ? kvm_mmu_write+0x2f/0x31
[ 40.003670] [c01370d6] ? autoremove_wake_function+0x0/0x33
[ 40.003670] [c011833d] ? kvm_set_pte_at+0x43/0x4b
[ 40.003670] [c015481f] ? unlock_page+0x25/0x28
[ 40.003670] [c015fe85] ? __do_fault+0x3fa/0x436
[ 40.003670] [c0478e20] ? _spin_unlock_bh+0xd/0xf
[ 40.003670] [c03dfe09] ? sys_recvfrom+0x7b/0xbd
[ 40.003670] [c01393f2] ? hrtimer_forward+0xd7/0xed
[ 40.003670] [c0123848] ? scheduler_tick+0x1ac/0x26d
[ 40.003670] [c013b414] ? getnstimeofday+0x2f/0xb4
[ 40.003670] [c03dfe63] ? sys_recv+0x18/0x1a
[ 40.003670] [c03e01d1] ? sys_socketcall+0x10a/0x186
[ 40.003670] [c012b547] ? irq_exit+0x53/0x6b
[ 40.003670] [c0107b1e] ? syscall_call+0x7/0xb
[ 40.003670] [c047] ? serial8250_remove+0x31/0x35
[ 40.003670] ===
[ 40.003670
Re: [kvm-devel] kernel BUG at drivers/virtio/virtio_ring.c:218!
On Friday 04 April 2008 01:46:21 pm Balaji Rao wrote:
Hi Rusty,
I hit a bug in virtio_ring.c:218 when I was stressing virtio_net using kvm
with -smp 4.
static void vring_disable_cb(struct virtqueue *_vq)
{
struct vring_virtqueue *vq = to_vvq(_vq);
START_USE(vq);
--BUG_ON(vq-vring.avail-flags VRING_AVAIL_F_NO_INTERRUPT);
vq-vring.avail-flags |= VRING_AVAIL_F_NO_INTERRUPT;
END_USE(vq);
}
Going through the source code, I felt that this BUG_ON is not required as any
CPU could race and call disable_cb when one
cpu still believes that its enabled. To validate my understanding, I
commented out the BUG_ON and everything worked
perfectly well.
I also get a lot of Unlikely: restart svq race on my console. Under high
load conditions, a race could occur very often
and I'm not sure if that signals a buggy situation. We could printk_ratelimit
if at all we need to retain it.
If you agree, I'll send a patch to this.
Christian Borntraeger CCed.
BTW, this is with respect to kvm.git, not a version prior to
commit 4265f161b6bb7b31163671329b1142b9023bf4e3
Author: Christian Borntraeger [EMAIL PROTECTED]
Date: Fri Mar 14 14:17:05 2008 +0100
virtio: fix race in enable_cb
The above commit does not fix the problem.I see this oops even today. There is
a race happening between calls to enable_cb
and disable_cb.
--
regards,
Balaji Rao
Dept. of Mechanical Engineering,
National Institute of Technology Karnataka, India
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kernel BUG at drivers/virtio/virtio_ring.c:218!
Hi Rusty,
I hit a bug in virtio_ring.c:218 when I was stressing virtio_net using kvm with
-smp 4.
static void vring_disable_cb(struct virtqueue *_vq)
{
struct vring_virtqueue *vq = to_vvq(_vq);
START_USE(vq);
--BUG_ON(vq-vring.avail-flags VRING_AVAIL_F_NO_INTERRUPT);
vq-vring.avail-flags |= VRING_AVAIL_F_NO_INTERRUPT;
END_USE(vq);
}
Going through the source code, I felt that this BUG_ON is not required as any
CPU could race and call disable_cb when one
cpu still believes that its enabled. To validate my understanding, I commented
out the BUG_ON and everything worked
perfectly well.
I also get a lot of Unlikely: restart svq race on my console. Under high load
conditions, a race could occur very often
and I'm not sure if that signals a buggy situation. We could printk_ratelimit
if at all we need to retain it.
If you agree, I'll send a patch to this.
--
thanks and regards,
Balaji Rao
Dept. of Mechanical Engineering,
National Institute of Technology Karnataka, India
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Mark kobjects as unitialized
On Monday 10 March 2008 09:22:00 pm Greg KH wrote: On Sun, Mar 09, 2008 at 12:51:15PM +0530, Balaji Rao wrote: On Sunday 09 March 2008 12:33:07 pm Greg KH wrote: snip Hi, This patch does not fix it all! The problem is in fact more involved. I also get these BUG reports when I reload kvm-intel. BUG kmalloc-8: Object already free [ 74.696570] - [ 74.696596] [ 74.697310] INFO: Allocated in strndup_user+0x30/0x62 age=587 cpu=2 pid=1439 [ 74.697845] INFO: Freed in kobject_set_name_vargs+0x29/0x32 age=559 cpu=3 pid=1439 [ 74.698008] INFO: Slab 0xc16f93a0 used=10 fp=0xf7c9d2d8 flags=0x1c3 [ 74.698008] INFO: Object 0xf7c9d1f8 @offset=504 fp=0xf7c9d578 This happens because, sysdev_class_register assigns a name to the kobject, and kfrees the old name if any. The poisoned 'name' object persists in case of statically allocated kobjects and as its passed to kfree again when re registered, we get the above warning. So, AFAICS the best way to solve this is by fixing the kobject users (kvm, oprofile etc.) to use dynamic kobjects instead of static ones or memset the kobject to zero before passing it to sysdev_register. I like the memset idea, how about this patch instead? thanks, greg k-h --- a/drivers/base/sys.c +++ b/drivers/base/sys.c @@ -133,6 +133,7 @@ int sysdev_class_register(struct sysdev_ pr_debug(Registering sysdev class '%s'\n, kobject_name(cls-kset.kobj)); INIT_LIST_HEAD(cls-drivers); + memset(cls-kset.kobj, 0x00, sizeof(struct kobject)); cls-kset.kobj.parent = system_kset-kobj; cls-kset.kobj.ktype = ktype_sysdev_class; cls-kset.kobj.kset = system_kset; This should work.But I am afraid if we zeroed it, the kfree poison test wouldn't catch even the genuine cases. Isn't it ? CMIIW. What genuine cases? kobjects should always be initialized to zero before they are registered. The cases in which a freed kobject is passed to the register function ? Probably they will be caught when do a memset.. A better fix according to me would be to zero the kobject in the places where we know it is being re-registered (kvm, oprofile) etc. This should do for now. But we should fix the sys_device users later, for the next cycle. Are you sure you know all of the sysdev_class objects that can be re-registered? Hmm.. Right. No, I only know that KVM and Oprofile use it. Can you test this patch out? Yes the idea works. One more memset is needed in sysdev_register. Here's the final patch. diff --git a/drivers/base/sys.c b/drivers/base/sys.c index 2f79c55..7c839d9 100644 --- a/drivers/base/sys.c +++ b/drivers/base/sys.c @@ -133,6 +133,7 @@ int sysdev_class_register(struct sysdev_class * cls) pr_debug(Registering sysdev class '%s'\n, kobject_name(cls-kset.kobj)); INIT_LIST_HEAD(cls-drivers); + memset(cls-kset.kobj, 0x00, sizeof(struct kobject)); cls-kset.kobj.parent = system_kset-kobj; cls-kset.kobj.ktype = ktype_sysdev_class; cls-kset.kobj.kset = system_kset; @@ -227,6 +228,7 @@ int sysdev_register(struct sys_device * sysdev) pr_debug(Registering sys device '%s'\n, kobject_name(sysdev-kobj)); + memset(sysdev-kobj, 0x00, sizeof(struct kobject)); /* Make sure the kset is set */ sysdev-kobj.kset = cls-kset; Yes, you're right. This also means I can drop the kobject_cleanup() patch from you as well, as that should no longer be needed, right? Yes, That's no longer needed. I am resending the patch, as the previous one had some whitespace issues. Signed-off-by: Balaji Rao [EMAIL PROTECTED] Tested-by: Mikael Pettersson [EMAIL PROTECTED] diff --git a/drivers/base/sys.c b/drivers/base/sys.c index 2f79c55..7c839d9 100644 --- a/drivers/base/sys.c +++ b/drivers/base/sys.c @@ -133,6 +133,7 @@ int sysdev_class_register(struct sysdev_class * cls) pr_debug(Registering sysdev class '%s'\n, kobject_name(cls-kset.kobj)); INIT_LIST_HEAD(cls-drivers); + memset(cls-kset.kobj, 0x00, sizeof(struct kobject)); cls-kset.kobj.parent = system_kset-kobj; cls-kset.kobj.ktype = ktype_sysdev_class; cls-kset.kobj.kset = system_kset; @@ -227,6 +228,7 @@ int sysdev_register(struct sys_device * sysdev) pr_debug(Registering sys device '%s'\n, kobject_name(sysdev-kobj)); + memset(sysdev-kobj, 0x00, sizeof(struct kobject)); /* Make sure the kset is set */ sysdev-kobj.kset = cls-kset; -- regards, balaji rao 3rd year, Dept. of Mechanical
Re: [kvm-devel] [PATCH] Mark kobjects as unitialized
On Thursday 06 March 2008 11:35:59 pm Greg KH wrote:
On Thu, Mar 06, 2008 at 11:20:50PM +0530, Balaji Rao wrote:
On Thursday 06 March 2008 10:35:14 pm Greg KH wrote:
snip
Where exactly in the code does that happen? kobjects should not be
reused as that implies that they are static, and not dynamically
allocated, right?
Which kobject is this?
Yes, its static. Here's the code from virt/kvm_main.c:1269
static struct sys_device kvm_sysdev = {
.id = 0,
.cls = kvm_sysdev_class,
};
this sys_device is being registered/unregistered when kvm-intel is
loaded/unloaded.
Ah, ok. I'll add this patch then.
Ugh, is this the sys_device stuff? I hate that code...
Yes it is! But, why do you hate it ?
For reasons like this :)
kobjects should not be static. the sysdevice stuff was a hack when it
was originally created and never touched since the mid 2.5 days. It
needs to be fixed up a lot, and is on my TODO list, slowly getting
closer to the top...
Hi,
This patch does not fix it all! The problem is in fact more involved. I also
get these BUG reports when I reload kvm-intel.
BUG kmalloc-8: Object already free
[ 74.696570]
-
[ 74.696596]
[ 74.697310] INFO: Allocated in strndup_user+0x30/0x62 age=587 cpu=2 pid=1439
[ 74.697845] INFO: Freed in kobject_set_name_vargs+0x29/0x32 age=559 cpu=3
pid=1439
[ 74.698008] INFO: Slab 0xc16f93a0 used=10 fp=0xf7c9d2d8 flags=0x1c3
[ 74.698008] INFO: Object 0xf7c9d1f8 @offset=504 fp=0xf7c9d578
This happens because, sysdev_class_register assigns a name to the kobject, and
kfrees the old name if any. The
poisoned 'name' object persists in case of statically allocated kobjects and as
its passed to kfree again when re
registered, we get the above warning.
So, AFAICS the best way to solve this is by fixing the kobject users (kvm,
oprofile etc.) to use dynamic kobjects instead
of static ones or memset the kobject to zero before passing it to
sysdev_register.
Greg ?
--
regards,
balaji rao
3rd year,
Dept. of Mechanical Engineering,
National Institute of Technology, Karnataka
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Mark kobjects as unitialized
On Sunday 09 March 2008 10:36:49 am Greg KH wrote:
On Sun, Mar 09, 2008 at 03:37:16AM +0530, Balaji Rao wrote:
On Thursday 06 March 2008 11:35:59 pm Greg KH wrote:
On Thu, Mar 06, 2008 at 11:20:50PM +0530, Balaji Rao wrote:
On Thursday 06 March 2008 10:35:14 pm Greg KH wrote:
snip
Where exactly in the code does that happen? kobjects should not be
reused as that implies that they are static, and not dynamically
allocated, right?
Which kobject is this?
Yes, its static. Here's the code from virt/kvm_main.c:1269
static struct sys_device kvm_sysdev = {
.id = 0,
.cls = kvm_sysdev_class,
};
this sys_device is being registered/unregistered when kvm-intel is
loaded/unloaded.
Ah, ok. I'll add this patch then.
Ugh, is this the sys_device stuff? I hate that code...
Yes it is! But, why do you hate it ?
For reasons like this :)
kobjects should not be static. the sysdevice stuff was a hack when it
was originally created and never touched since the mid 2.5 days. It
needs to be fixed up a lot, and is on my TODO list, slowly getting
closer to the top...
Hi,
This patch does not fix it all! The problem is in fact more involved.
I also get these BUG reports when I reload kvm-intel.
BUG kmalloc-8: Object already free
[ 74.696570]
-
[ 74.696596]
[ 74.697310] INFO: Allocated in strndup_user+0x30/0x62 age=587 cpu=2
pid=1439
[ 74.697845] INFO: Freed in kobject_set_name_vargs+0x29/0x32 age=559
cpu=3 pid=1439
[ 74.698008] INFO: Slab 0xc16f93a0 used=10 fp=0xf7c9d2d8 flags=0x1c3
[ 74.698008] INFO: Object 0xf7c9d1f8 @offset=504 fp=0xf7c9d578
This happens because, sysdev_class_register assigns a name to the
kobject, and kfrees the old name if any. The poisoned 'name' object
persists in case of statically allocated kobjects and as its passed to
kfree again when re registered, we get the above warning.
Ugh, that's horrible. And people wonder why I hate the sysdev code :)
Does it also mean that when we do cleanup sysdev devices, we are freeing
a name that might not have been dynamically allocated? If so, we need
to fix that as well.
No, that doesn't happen. We free the name only if it is allocated..
A simple 'strdup' of the class name in sysdev_class_register() should
fix all of this, right?
So, AFAICS the best way to solve this is by fixing the kobject users
(kvm, oprofile etc.) to use dynamic kobjects instead of static ones or
memset the kobject to zero before passing it to sysdev_register.
Yes, that would be great to fix up, but probably unlikly so late in the
release cycle.
How about the patch below, does it work for you? (build tested only)
thanks,
greg k-h
---
drivers/base/sys.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/base/sys.c
+++ b/drivers/base/sys.c
@@ -130,13 +130,16 @@ static struct kset *system_kset;
int sysdev_class_register(struct sysdev_class * cls)
{
+ char *name;
+
pr_debug(Registering sysdev class '%s'\n,
kobject_name(cls-kset.kobj));
INIT_LIST_HEAD(cls-drivers);
cls-kset.kobj.parent = system_kset-kobj;
cls-kset.kobj.ktype = ktype_sysdev_class;
cls-kset.kobj.kset = system_kset;
- kobject_set_name(cls-kset.kobj, cls-name);
+ name = kstrdup(cls-name, GFP_KERNEL);
+ kobject_set_name(cls-kset.kobj, name);
return kset_register(cls-kset);
}
--
regards,
balaji rao
3rd year,
Dept. of Mechanical Engineering,
National Institute of Technology, Karnataka
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Mark kobjects as unitialized
On Sunday 09 March 2008 12:03:08 pm Greg KH wrote:
On Sun, Mar 09, 2008 at 03:37:16AM +0530, Balaji Rao wrote:
On Thursday 06 March 2008 11:35:59 pm Greg KH wrote:
On Thu, Mar 06, 2008 at 11:20:50PM +0530, Balaji Rao wrote:
On Thursday 06 March 2008 10:35:14 pm Greg KH wrote:
snip
Where exactly in the code does that happen? kobjects should not be
reused as that implies that they are static, and not dynamically
allocated, right?
Which kobject is this?
Yes, its static. Here's the code from virt/kvm_main.c:1269
static struct sys_device kvm_sysdev = {
.id = 0,
.cls = kvm_sysdev_class,
};
this sys_device is being registered/unregistered when kvm-intel is
loaded/unloaded.
Ah, ok. I'll add this patch then.
Ugh, is this the sys_device stuff? I hate that code...
Yes it is! But, why do you hate it ?
For reasons like this :)
kobjects should not be static. the sysdevice stuff was a hack when it
was originally created and never touched since the mid 2.5 days. It
needs to be fixed up a lot, and is on my TODO list, slowly getting
closer to the top...
Hi,
This patch does not fix it all! The problem is in fact more involved. I
also get these BUG reports when I reload
kvm-intel.
BUG kmalloc-8: Object already free
[ 74.696570]
-
[ 74.696596]
[ 74.697310] INFO: Allocated in strndup_user+0x30/0x62 age=587 cpu=2
pid=1439
[ 74.697845] INFO: Freed in kobject_set_name_vargs+0x29/0x32 age=559
cpu=3 pid=1439
[ 74.698008] INFO: Slab 0xc16f93a0 used=10 fp=0xf7c9d2d8 flags=0x1c3
[ 74.698008] INFO: Object 0xf7c9d1f8 @offset=504 fp=0xf7c9d578
This happens because, sysdev_class_register assigns a name to the
kobject, and kfrees the old name if any. The poisoned 'name' object
persists in case of statically allocated kobjects and as its passed to
kfree again when re registered, we get the above warning.
So, AFAICS the best way to solve this is by fixing the kobject users
(kvm, oprofile etc.) to use dynamic kobjects instead of static ones or
memset the kobject to zero before passing it to sysdev_register.
I like the memset idea, how about this patch instead?
thanks,
greg k-h
--- a/drivers/base/sys.c
+++ b/drivers/base/sys.c
@@ -133,6 +133,7 @@ int sysdev_class_register(struct sysdev_
pr_debug(Registering sysdev class '%s'\n,
kobject_name(cls-kset.kobj));
INIT_LIST_HEAD(cls-drivers);
+ memset(cls-kset.kobj, 0x00, sizeof(struct kobject));
cls-kset.kobj.parent = system_kset-kobj;
cls-kset.kobj.ktype = ktype_sysdev_class;
cls-kset.kobj.kset = system_kset;
This should work.But I am afraid if we zeroed it, the kfree poison test
wouldn't catch even the genuine cases. Isn't it ?
CMIIW.
A better fix according to me would be to zero the kobject in the places where
we know it is being re-registered (kvm,
oprofile) etc. This should do for now. But we should fix the sys_device users
later, for the next cycle.
--
regards,
balaji rao
3rd year,
Dept. of Mechanical Engineering,
National Institute of Technology, Karnataka
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Mark kobjects as unitialized
On Sunday 09 March 2008 12:33:07 pm Greg KH wrote: snip Hi, This patch does not fix it all! The problem is in fact more involved. I also get these BUG reports when I reload kvm-intel. BUG kmalloc-8: Object already free [ 74.696570] - [ 74.696596] [ 74.697310] INFO: Allocated in strndup_user+0x30/0x62 age=587 cpu=2 pid=1439 [ 74.697845] INFO: Freed in kobject_set_name_vargs+0x29/0x32 age=559 cpu=3 pid=1439 [ 74.698008] INFO: Slab 0xc16f93a0 used=10 fp=0xf7c9d2d8 flags=0x1c3 [ 74.698008] INFO: Object 0xf7c9d1f8 @offset=504 fp=0xf7c9d578 This happens because, sysdev_class_register assigns a name to the kobject, and kfrees the old name if any. The poisoned 'name' object persists in case of statically allocated kobjects and as its passed to kfree again when re registered, we get the above warning. So, AFAICS the best way to solve this is by fixing the kobject users (kvm, oprofile etc.) to use dynamic kobjects instead of static ones or memset the kobject to zero before passing it to sysdev_register. I like the memset idea, how about this patch instead? thanks, greg k-h --- a/drivers/base/sys.c +++ b/drivers/base/sys.c @@ -133,6 +133,7 @@ int sysdev_class_register(struct sysdev_ pr_debug(Registering sysdev class '%s'\n, kobject_name(cls-kset.kobj)); INIT_LIST_HEAD(cls-drivers); + memset(cls-kset.kobj, 0x00, sizeof(struct kobject)); cls-kset.kobj.parent = system_kset-kobj; cls-kset.kobj.ktype = ktype_sysdev_class; cls-kset.kobj.kset = system_kset; This should work.But I am afraid if we zeroed it, the kfree poison test wouldn't catch even the genuine cases. Isn't it ? CMIIW. What genuine cases? kobjects should always be initialized to zero before they are registered. The cases in which a freed kobject is passed to the register function ? Probably they will be caught when do a memset.. A better fix according to me would be to zero the kobject in the places where we know it is being re-registered (kvm, oprofile) etc. This should do for now. But we should fix the sys_device users later, for the next cycle. Are you sure you know all of the sysdev_class objects that can be re-registered? Hmm.. Right. No, I only know that KVM and Oprofile use it. Can you test this patch out? Yes the idea works. One more memset is needed in sysdev_register. Here's the final patch. diff --git a/drivers/base/sys.c b/drivers/base/sys.c index 2f79c55..7c839d9 100644 --- a/drivers/base/sys.c +++ b/drivers/base/sys.c @@ -133,6 +133,7 @@ int sysdev_class_register(struct sysdev_class * cls) pr_debug(Registering sysdev class '%s'\n, kobject_name(cls-kset.kobj)); INIT_LIST_HEAD(cls-drivers); + memset(cls-kset.kobj, 0x00, sizeof(struct kobject)); cls-kset.kobj.parent = system_kset-kobj; cls-kset.kobj.ktype = ktype_sysdev_class; cls-kset.kobj.kset = system_kset; @@ -227,6 +228,7 @@ int sysdev_register(struct sys_device * sysdev) pr_debug(Registering sys device '%s'\n, kobject_name(sysdev-kobj)); + memset(sysdev-kobj, 0x00, sizeof(struct kobject)); /* Make sure the kset is set */ sysdev-kobj.kset = cls-kset; -- regards, balaji rao 3rd year, Dept. of Mechanical Engineering, National Institute of Technology, Karnataka - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-linux-1
On Thursday 06 March 2008 04:01:53 pm Jun Koi wrote: On 3/6/08, Avi Kivity [EMAIL PROTECTED] wrote: This is the first release of block and network drivers for Linux guests running on a kvm host. The drivers are intended for guest kernels 2.6.18-2.6.24. Newer kernels include the drivers; older kernels may not work. kvm-61 or later is needed in the host. Network throughput is around 1 Gbit/sec; latency is currently a less than stellar 0.3 msec. Both these figures will be improved in the future. The drivers are available from the download page of the kvm website, below. To use, download the drivers into the guest (using one of the emulated network cards), unpack the package, and type make sudo make install You will need the kernel development package installed. Excellent, thanks! Just 1 question: Above is the instruction for guest. How about the host? Dont we need to install anything?? I suppose that qemu in the latest kvm package already supported virtio, but I think we need some support from host kernel as well? Hi Jun, No, AFAIK we don't need any support from the host kernel. We just need a virtio backend to be present in qemu, which is there in the latest kvm-userspace. -- regards, balaji rao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Mark kobjects as unitialized
Hi greg, When I remove only the kvm-intel module without removing the kvm module itself, I get an error saying that a kobject is trying to be reinitialized. Its because of the fact that kvm reuses a kobject in kvm_init when calling sysdev_register. This patch fixes kobject_cleanup by marking the kobject as uninitialized when we cleanup to allow kobjects to be reused. Signed-off-by: Balaji Rao [EMAIL PROTECTED] diff --git a/lib/kobject.c b/lib/kobject.c index 0d03252..fbdefb8 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -577,6 +577,9 @@ static void kobject_cleanup(struct kobject *kobj) pr_debug(kobject: '%s': free name\n, name); kfree(name); } + + /* Set the state to uninitialized */ + kobj-state_initialized = 0; } static void kobject_release(struct kref *kref) -- regards, balaji rao 3rd year, Dept. of Mechanical Engineering, National Institute of Technology, Karnataka - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Mark kobjects as unitialized
On Thursday 06 March 2008 10:35:14 pm Greg KH wrote:
snip
Where exactly in the code does that happen? kobjects should not be
reused as that implies that they are static, and not dynamically
allocated, right?
Which kobject is this?
Yes, its static. Here's the code from virt/kvm_main.c:1269
static struct sys_device kvm_sysdev = {
.id = 0,
.cls = kvm_sysdev_class,
};
this sys_device is being registered/unregistered when kvm-intel is
loaded/unloaded.
Ugh, is this the sys_device stuff? I hate that code...
Yes it is! But, why do you hate it ?
--
regards,
balaji rao
3rd year,
Dept. of Mechanical Engineering,
National Institute of Technology, Karnataka
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] problem booting linux kernel directly with virtio
Hello all,
When I try to run kvm with the following command line,
/usr/bin/qemu-system-x86_64 -m 1024 -kernel
/kernels/git/kvm/arch/x86/boot/bzImage -append root=/dev/sda -drive
file=f8.img,boot=on,if=virtio
I get an error saying 'A disk image must be given for 'hda' when booting a
Linux kernel'
I traced it to the following piece of code in kvm-userspace/qemu/hw/pc.c
static void generate_bootsect(uint32_t gpr[8], uint16_t segs[6], uint16_t ip)
..
...
hda = drive_get_index(IF_IDE, 0, 0);
if (hda == -1) {
fprintf(stderr, A disk image must be given for 'hda' when booting
a Linux kernel\n);
exit(1);
}
This function then proceeds to change the bootloader to boot the kernel
directly.
Changing IF_IDE to IF_VIRTIO made kvm to run normally. So, i think we should
not check for hda here, but for the boot disk.
I tried to fix it, but I could not figure out any clean way of obtaining the
boot disk. Please help.
--
regards,
balaji rao
NITK
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC] Performance monitoring units and KVM
Hi all! Earlier it was suggested that we go ahead with emulating Perf Mon Events in exposing it to the guest. The serious limitation in this approach is that we end up exposing only a small number of events to the guest, even though the host hardware is capable of much more. The only benefit this approach offers is that, it doesn't break live migration. The other option is to pass through the real PMU to the guest. I believe this approach is far better in the sense that, 1. All the available events in the host hardware can be passed on to the guest, which can be used by oprofile to profile the guest and trackdown slowdowns introduced due to virtualization. 2. Its much cleaner and easier to pass through the PMU. Yes, this approach breaks live migration. Migration should not be possible *only* when the PMU is being used by oprofile. We can mark the guest as unmigratable in such situations. Once the PMU is not being used, migration can be performed normally. Note, this requires a small change to oprofile source. Upon migration, oprofile should be made to re-identify the CPU and use the perf mon events appropriate to that CPU. I think this could be done by having a migrate_notifier, or something like that.. Please provide comments on this. -- regards, balaji rao NITK - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Performance monitoring units and KVM
On Sunday 17 February 2008 03:34:43 am Anthony Liguori wrote: Balaji Rao wrote: Hi all! Earlier it was suggested that we go ahead with emulating Perf Mon Events in exposing it to the guest. The serious limitation in this approach is that we end up exposing only a small number of events to the guest, even though the host hardware is capable of much more. The only benefit this approach offers is that, it doesn't break live migration. I think performance monitors are no different than anything else in KVM. We should virtualize as much as possible and by default provide only the common subset to the guest supported by the majority of hardware. Then we can use mechanisms like QEMU's CPU support to enable additional features that may be available and unique to the underlying hardware. It's then up to the management tools to deal with migratability since they've explicitly enabled the feature. Sorry, I don't understand how it can done through QEMU, but according to what I understand, it makes migration very difficult/impossible. So, why should we go for this approach at all ? Its the very reason direct access to PMU was thought of as a bad idea. Do you see any other problem in directly exposing the PMU ? -- regards, balaji rao NITK - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Query on migration
Hello all, When going through orpofile code, I noticed that boot_cpu_data was used to determine CPU vendor, family etc. Will this be updated on migration to a different Machine say, from Intel to AMD ? If not, wouldn't it cause problems ? Please clarify. -- regards, balaji rao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] nmi watchdog in kvm
On Wednesday 30 January 2008 04:13:58 pm Avi Kivity wrote:
@@ -790,6 +795,18 @@ static int apic_mmio_range(struct kvm_io_device
*this, gpa_t addr) return ret;
}
+static int nmi_notify(struct notifier_block *self,unsigned long val,
void *data) { +
+struct kvm *kvm;
+kvm = list_entry(vm_list.next, struct kvm, vm_list);
+ kvm_x86_ops-inject_nmi(kvm-vcpus[0]);
+return NOTIFY_STOP;
+}
You're not guaranteed to be in vcpu context here, that's what's causing
the vmwrite errors.
I intended to do this here. Looks like its not the right way to check for
presence in vcpu context. How do i do it ? please explain.
+static void vmx_inject_nmi(struct kvm_vcpu *vcpu) {
+
+ struct vcpu_vmx * vmx = to_vmx(vcpu);
+ if (vmx-launched)
+ vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
+ 2 | INTR_TYPE_NMI | INTR_INFO_VALID_MASK);
+}
regards,
balaji rao
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] nmi watchdog in kvm
On Wednesday 30 January 2008 08:09:32 pm Avi Kivity wrote:
I intended to do this here. Looks like its not the right way to check for
presence in vcpu context. How do i do it ? please explain.
+static void vmx_inject_nmi(struct kvm_vcpu *vcpu) {
+
+ struct vcpu_vmx * vmx = to_vmx(vcpu);
+ if (vmx-launched)
+ vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
+ 2 | INTR_TYPE_NMI | INTR_INFO_VALID_MASK);
+}
No, this is the wrong place. If you have a vcpu, you'd better be in
vcpu context.
Oh.. ok. Looks like I have not understood the vcpu concept correctly. Will put
more thought into it and understand it before I attempt to fix this.
thank you,
balaji rao
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Performance monitoring units and KVM
On Wednesday 30 January 2008 11:11:51 pm Avi Kivity wrote: Markus Armbruster wrote: System-wide profiling of the *virtual* machine is related to profiling just a process. That's hard. I guess building on Perfmon2 would make sense there, but as long as it's out of tree... Can we wait for it? If not, what then? Give the guest access to the real PMU. Save them on every exit (switching profiling off), and restore them on every entry (switching profiling on). The only problem with this is that it is very cpu model dependent, losing the hardware independence that virtual machines have. If you are satisfied with the architectural performance counters, then we even have hardware independence. But don't the architectural performance counters vary between Intel and AMD cpus ? AFAIK, they do. And, this would pose problems during migration between Intel and AMD hosts. I am not sure how important is it to support migration between Intel and AMD hosts. If it were not that important, then IMO we could go ahead with exposing the real PMU. Maybe we could warn users against running profilers in the guest if they intend it to to be Intel-AMD migrateable ? regards, balaji rao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Performance monitoring units and KVM
On Thursday 31 January 2008 08:42:32 am Andi Kleen wrote: On Thu, Jan 31, 2008 at 12:44:10AM +0530, Balaji Rao wrote: On Wednesday 30 January 2008 11:56:25 pm Andi Kleen wrote: There is no really an architectural PMU if you consider boxes beyond relatively new Intel CPUs (which got one) But since kvm runs only on such CPUs, it should not really be a problem in migrating between various Intel models at least. I'm not 100% sure, but I think there are P4 based (Family 15) CPUs which have VT but not ArchPerfMon. AFAIK ArchPerfMon is only in Family 6 CPUs. Family 15 has a completely different PerfMon interface. Yea, you are right. To quote from the manual (2.1.7), 'Intel® Virtualization Technology (Intel® VT) was introduced in the Intel Pentium 4 processor 672 and 662.' And they dont have ArchPerfMon as it was introduced only after core solo and duo. regards, balaji rao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC] nmi watchdog in kvm
); /* 22.3.1.5 */
/* Control */
@@ -1786,6 +1792,14 @@ out:
return ret;
}
+static void vmx_inject_nmi(struct kvm_vcpu *vcpu) {
+
+ struct vcpu_vmx * vmx = to_vmx(vcpu);
+ if (vmx-launched)
+ vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
+ 2 | INTR_TYPE_NMI | INTR_INFO_VALID_MASK);
+}
+
static void vmx_inject_irq(struct kvm_vcpu *vcpu, int irq)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -2686,6 +2700,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
.exception_injected = vmx_exception_injected,
.inject_pending_irq = vmx_intr_assist,
.inject_pending_vectors = do_interrupt_requests,
+ .inject_nmi = vmx_inject_nmi,
.set_tss_addr = vmx_set_tss_addr,
};
@@ -2700,7 +2715,11 @@ static int __init vmx_init(void)
return -ENOMEM;
vmx_io_bitmap_b = alloc_page(GFP_KERNEL | __GFP_HIGHMEM);
- if (!vmx_io_bitmap_b) {
+ if (!vmx_io_bitmap_b)
+ r = -ENOMEM;
+
+ vmx_msr_bitmap = alloc_page(GFP_KERNEL | __GFP_HIGHMEM);
+ if (!vmx_msr_bitmap) {
r = -ENOMEM;
goto out;
}
@@ -2718,6 +2737,15 @@ static int __init vmx_init(void)
memset(iova, 0xff, PAGE_SIZE);
kunmap(vmx_io_bitmap_b);
+ iova = kmap(vmx_msr_bitmap);
+ memset(iova, 0xff, PAGE_SIZE);
+ /* Enable direct access to first perfmon MSR */
+ clear_bit(MSR_P6_PERFCTR0, iova);
+ clear_bit(MSR_P6_EVNTSEL0, iova);
+ clear_bit(MSR_P6_PERFCTR0, iova + 2048);
+ clear_bit(MSR_P6_EVNTSEL0, iova + 2048);
+ kunmap(vmx_msr_bitmap);
+
set_bit(0, vmx_vpid_bitmap); /* 0 is reserved for host */
r = kvm_init(vmx_x86_ops, sizeof(struct vcpu_vmx), THIS_MODULE);
@@ -2730,8 +2758,9 @@ static int __init vmx_init(void)
return 0;
out1:
- __free_page(vmx_io_bitmap_b);
+ __free_page(vmx_msr_bitmap);
out:
+ __free_page(vmx_io_bitmap_b);
__free_page(vmx_io_bitmap_a);
return r;
}
@@ -2740,6 +2769,7 @@ static void __exit vmx_exit(void)
{
__free_page(vmx_io_bitmap_b);
__free_page(vmx_io_bitmap_a);
+ __free_page(vmx_msr_bitmap);
kvm_exit();
}
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 436ce0f..1b6d6a8 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -242,6 +242,7 @@ enum vmcs_field {
#define VECTORING_INFO_VALID_MASK INTR_INFO_VALID_MASK
#define INTR_TYPE_EXT_INTR (0 8) /* external interrupt */
+#define INTR_TYPE_NMI (2 8)
#define INTR_TYPE_EXCEPTION (3 8) /* processor exception */
#define INTR_TYPE_SOFT_INTR (4 8) /* software interrupt */
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 67ae307..f17248d 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -387,6 +387,7 @@ struct kvm_x86_ops {
void (*queue_exception)(struct kvm_vcpu *vcpu, unsigned nr,
bool has_error_code, u32 error_code);
bool (*exception_injected)(struct kvm_vcpu *vcpu);
+ void (*inject_nmi)(struct kvm_vcpu *vcpu);
void (*inject_pending_irq)(struct kvm_vcpu *vcpu);
void (*inject_pending_vectors)(struct kvm_vcpu *vcpu,
struct kvm_run *run);
---
thanks,
balaji rao
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] nmi watchdog in kvm
On Monday 28 January 2008 08:30:32 pm Joerg Roedel wrote: On Mon, Jan 28, 2008 at 08:12:26PM +0530, Balaji Rao wrote: On Monday 28 January 2008 05:59:25 pm Joerg Roedel wrote: This patch kills the ability of KVM to migrate between AMD and Intel because the Intel performance counters are not available on AMD and vice verca. Yes. The way we should solve this is by emulating the MSRs. Am not sure about the overhead involved. What are your thoughts on this ? I think you can't do this with performance counters in KVM (except you emulate the Intel PerfCtrs on AMD and the AMD PerfCtrs on Intel, which might not be possible, at least very painfull). I think the best solution to implement a watchdog for KVM is to implement another NMI source, e.g. emulating a watchdog PCI card in QEMU. Yes, it would be painful to emulate non native perform counters.. But having a PCI device for generating NMIs would solve the problem of NMI Watchdogs. But we still wouldn't be able to provide perfmon counters to the guest.. But before that, we need to decide whether it is needed to provide perfmon counters to the guest or not. To make the guest use QEmu's PCI we need to pass another kernel param (say, nmi_watchdog=3) which is not very nice.So, can't we implement NMI watchdog using paravirt ? Or the other option would be to probe for the NMI Watchdog PCI card before trying to use other means of generating NMIs.. Could anyone please point me to any docs on writing a QEmu PCI device driver ? regards, balaji rao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] nmi watchdog in kvm
On Monday 28 January 2008 05:59:25 pm Joerg Roedel wrote:
On Mon, Jan 28, 2008 at 01:48:40PM +0530, Balaji Rao wrote:
Hello,
I was trying to enable the use of nmi watchdog within a linux guest
running in kvm. I have done it by allowing direct access to perfmon msrs
using the MSR_BITMAP field in vmcs region.
Is there a proper virtualization of the performance counter MSRs on
Intel? If not this patch will destroy any host side performance
monitoring.
No. It has to be handled by the VMM. I shall do this in a later patch. This is
just a quick and dirty attempt to solve this problem.
snip
This patch kills the ability of KVM to migrate between AMD and Intel
because the Intel performance counters are not available on AMD and vice
verca.
Yes. The way we should solve this is by emulating the MSRs. Am not sure about
the overhead involved. What are your thoughts on this ?
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 67ae307..f17248d 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -387,6 +387,7 @@ struct kvm_x86_ops {
void (*queue_exception)(struct kvm_vcpu *vcpu, unsigned nr,
bool has_error_code, u32 error_code);
bool (*exception_injected)(struct kvm_vcpu *vcpu);
+ void (*inject_nmi)(struct kvm_vcpu *vcpu);
The implementation of this new callback for SVM is missing.
I just wanted to get it running on my hardware first! :) Will implement it for
SVM once I get the approach right.
void (*inject_pending_irq)(struct kvm_vcpu *vcpu);
void (*inject_pending_vectors)(struct kvm_vcpu *vcpu,
struct kvm_run *run);
---
thank you for the comments,
regards,
balaji rao
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] New to KVM
Hello people! I am new to the KVM community. I found it really exciting and am interested in contributing to the project. I found a TODO list at the site and decided to work on the following one. Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point. Is it already done ? Can i start working on it ? Any comments would be appreciated. Thanking you in advance, balaji rao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
