Re: [kvm-devel] Reverting back in lapic2 branch of kvm-userspace?

2007-07-24 Thread Avi Kivity
Dong, Eddie wrote:
 ???
 I didn't think the APIC is removed.
 Who and which commit?
   

commit 394b6efba95f21d22687743def9aa1a0b7125809
Author: Eddie Dong [EMAIL PROTECTED]
Date:   Thu Jul 19 12:12:53 2007 +0300

kvm: rename KVM_CAP_PIC to KVM_CAP_IRQCHIP

had parts of the patch that removed the apic capability bit from cpuid. 
I redid that commit, but I may have made more mistakes earlier.


 Eddie

 Avi Kivity wrote:
   
 He, Qing wrote:
 
 Avi/Eddie,
 I just noticed that the latest commit in lapic2 branch of
 kvm-userspace effectively disabled in-kernel apic and ioapic. I
 don't suppose it's intended, is it? 


   
 It was a mistake on my part.  I re-did the commit and pushed a new
 version (you need to fetch with +lapic2).

 Eddie, hopefully there aren't more mistakes like that, can you check?


 --
 Do not meddle in the internals of kernels, for they are subtle
 and quick to panic.
 


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [RFC 0/8]KVM: swap out guest pages

2007-07-24 Thread Rusty Russell
On Tue, 2007-07-24 at 08:30 +0300, Avi Kivity wrote:
 Rusty Russell wrote:
  On Mon, 2007-07-23 at 13:27 +0300, Avi Kivity wrote:

  Having an address_space (like your patch does) is remarkably simple, and 
  requires few hooks from the current vm.  However using existing vmas 
  mapped by the user has many advantages:
 
  - compatible with s390 requirements
  - allows the user to use hugetlbfs pages, which have a performance 
  advantage using ept/npt (but which are unswappable)
  - allows the user to map a file (which can be regarded as way to specify 
  the swap device)
  - better ingration with the rest of the vm
  
 
  You don't need to expose the vmas.  You just have userspace point out
  the start+len of each region of memory it wants the guest to be able to
  access, and the address it wants it to appear in the guest.
 
  This is a slight superset of what lguest does in two ways:
 
  1) my guest address == user address, but I'm looking at adding an offset
  so I don't have to link the launcher binary specially.
  2) I have only one contiguous region of guest-physical memory, since I
  can place device memory immediately above normal mem.
 

 
 My intent was to allow userspace to establish assign a virtual address
 range into a memory slot.
 
 So long as you don't do swapping, all is simple, since you can do a
 get_user_pages() on initialization or when installing a shadow pte.  But
 if you want to swap, you need:
 
 - a way to transfer the dirty bit from the shadow ptes to the struct page

Actually, get_user_pages() does that for you.  You have to make R/O any
writable pte where the guest doesn't set the dirty bit (so you can trap
it later) but last I put a printk in there, Linux doesn't do that.

 - a way to let the vm rmap know that there are shadow ptes that point to
 the page in addition to Linux ptes.  These shadow ptes may be in a
 different format than Linux ptes.
 - a different tlb invalidation method with ASIDs

Well first I was just going to see how well hooking into the shrinker
works.  That might be sufficient: just throw out shadow refs to pages
when there's pressure.

If not, it does get harder.  A callback in the mm struct to say I want
to swap your page out is required if we don't take a reference to the
page.  Dirty bit handling would be an interesting issue (maybe the
callback can say No! and dirty the page again?).

I fear mm code.

 It's not going to be simple.

Yeah, but it's one thing stopping lguest from being non-root usable, so
I want it there, too.

Cheers,
Rusty.



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [RFC 0/8]KVM: swap out guest pages

2007-07-24 Thread Rusty Russell
On Tue, 2007-07-24 at 09:21 +0300, Avi Kivity wrote:
 Rusty Russell wrote:
  Actually, get_user_pages() does that for you.  You have to make R/O any
  writable pte where the guest doesn't set the dirty bit (so you can trap
  it later) but last I put a printk in there, Linux doesn't do that.
 
 Don't understand.  You mean Linux always sets the dirty bit when it
 makes a page writable?  Surely some mistake.
 
 It probably does do so on demand write faults, but I'm sure the dirty
 bit can get cleaned out by the swapper.

Yeah, me dumb.  I should put that printk back and try doing a kernel
compile.

  If not, it does get harder.  A callback in the mm struct to say I want
  to swap your page out is required if we don't take a reference to the
  page.  Dirty bit handling would be an interesting issue (maybe the
  callback can say No! and dirty the page again?).
 
 Since we have rmap, I don't see that as an issue.  Given a page, we can
 easily drop all refs.  Though lguest doesn't do that, right?

Yeah, rmap might maul some puppies.  I could do poor man's rmap tho with
one backref and a bit to say there are more.  Then if that bit is set,
I just drop all 4 shadows 8)

 I'm also concerned with picking the correct page, but there's no good
 solution here.

But since you have rmap, if there was a cb when the the page was
undirtied, you could undirty the ptes.  When there I want to kick this
page out cb comes along, see if one of the ptes is now dirty, dirty the
page and return no.

Maybe it's too simplistic, but it might work.
Rusty.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Reverting back in lapic2 branch of kvm-userspace?

2007-07-24 Thread Dong, Eddie
O, I checked minutes ago (using local mirror), everthing is fine. 
I got live migration works for FC5_32 which uses PIC only.

Eddie

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [RFC 0/8]KVM: swap out guest pages

2007-07-24 Thread Avi Kivity
Rusty Russell wrote:

 If not, it does get harder.  A callback in the mm struct to say I want
 to swap your page out is required if we don't take a reference to the
 page.  Dirty bit handling would be an interesting issue (maybe the
 callback can say No! and dirty the page again?).
   
 Since we have rmap, I don't see that as an issue.  Given a page, we can
 easily drop all refs.  Though lguest doesn't do that, right?
 

 Yeah, rmap might maul some puppies.  I could do poor man's rmap tho with
 one backref and a bit to say there are more.  Then if that bit is set,
 I just drop all 4 shadows 8)

   

It's too poor.  A long running guest will eventually map all of memory
using the kernel page tables and a large proportion with user page
tables, so many pages will have that bit set.

However, you can probably work around that by not setting an rmap for
the kernel mappings, and instead have the guest teach the host where the
kernel page tables live.  You'd only be left with shared libraries,
until the kernel can share page tables for them too.

 I'm also concerned with picking the correct page, but there's no good
 solution here.
 

 But since you have rmap, if there was a cb when the the page was
 undirtied, you could undirty the ptes.  When there I want to kick this
 page out cb comes along, see if one of the ptes is now dirty, dirty the
 page and return no.

 Maybe it's too simplistic, but it might work.
   

Ah, I see what you mean now.  It could work, as far as I can tell (which
isn't very far, though).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

2007-07-24 Thread Rusty Russell
If the guest can invoke a printk(), it can potentially flood the logs,
causing a host DoS.  We should also indicate *which* guest we're
talking about.

This patch adds pr_guest (analogous to pr_debug) which ratelimits.
Not all printk's were replaced: some are only printed once and others
should probably be replaced by BUG().  I removed the kvm_printf in
init_rmode_tss: it says nothing that the return value doesn't say.

Coders should be aware that printing in the logs is not particularly
useful except to give feedback to developers. ie. should not be used
for chit-chat.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r 3f158ee9df43 drivers/kvm/kvm.h
--- a/drivers/kvm/kvm.h Tue Jul 24 16:22:39 2007 +1000
+++ b/drivers/kvm/kvm.h Tue Jul 24 17:01:15 2007 +1000
@@ -503,8 +503,18 @@ struct kvm_arch_ops {
 
 extern struct kvm_arch_ops *kvm_arch_ops;
 
-#define kvm_printf(kvm, fmt ...) printk(KERN_DEBUG fmt)
-#define vcpu_printf(vcpu, fmt...) kvm_printf(vcpu-kvm, fmt)
+/* The guest did something wrong/strange.  Returns true if printed. */
+#define pr_guest(vcpu, fmt, ...)   \
+   ({  \
+   int __r = 0;\
+   if (printk_ratelimit()) {   \
+   printk(KERN_WARNING kvm: %i: cpu%i  fmt,  \
+  current-tgid, (vcpu)-vcpu_id   \
+  , ## __VA_ARGS__);   \
+   __r = 1;\
+   }   \
+   __r;\
+   })
 
 int kvm_init_arch(struct kvm_arch_ops *ops, struct module *module);
 void kvm_exit_arch(void);
diff -r 3f158ee9df43 drivers/kvm/kvm_main.c
--- a/drivers/kvm/kvm_main.cTue Jul 24 16:22:39 2007 +1000
+++ b/drivers/kvm/kvm_main.cTue Jul 24 16:28:33 2007 +1000
@@ -425,8 +425,8 @@ inject_gp(struct kvm_vcpu *vcpu, const c
va_list args;
 
va_start(args, why_fmt);
-   printk(KERN_DEBUG kvm: #GP );
-   vprintk(why_fmt, args);
+   if (pr_guest(vcpu, #GP ))
+   vprintk(why_fmt, args);
va_end(args);
kvm_arch_ops-inject_gp(vcpu, 0);
 }
@@ -995,8 +995,8 @@ static int emulator_write_std(unsigned l
  unsigned int bytes,
  struct x86_emulate_ctxt *ctxt)
 {
-   printk(KERN_ERR emulator_write_std: addr %lx n %d\n,
-  addr, bytes);
+   pr_guest(ctxt-vcpu,
+emulator_write_std: addr %lx n %d\n, addr, bytes);
return X86EMUL_UNHANDLEABLE;
 }
 
@@ -1173,7 +1173,7 @@ int emulator_get_dr(struct x86_emulate_c
*dest = kvm_arch_ops-get_dr(vcpu, dr);
return X86EMUL_CONTINUE;
default:
-   printk(KERN_DEBUG %s: unexpected dr %u\n,
+   pr_guest(vcpu, %s: unexpected dr %u\n,
   __FUNCTION__, dr);
return X86EMUL_UNHANDLEABLE;
}
@@ -1386,7 +1386,7 @@ unsigned long realmode_get_cr(struct kvm
case 4:
return vcpu-cr4;
default:
-   vcpu_printf(vcpu, %s: unexpected cr %u\n, __FUNCTION__, cr);
+   pr_guest(vcpu, %s: unexpected cr %u\n, __FUNCTION__, cr);
return 0;
}
 }
@@ -1409,7 +1409,7 @@ void realmode_set_cr(struct kvm_vcpu *vc
set_cr4(vcpu, mk_cr_64(vcpu-cr4, val));
break;
default:
-   vcpu_printf(vcpu, %s: unexpected cr %u\n, __FUNCTION__, cr);
+   pr_guest(vcpu, %s: unexpected cr %u\n, __FUNCTION__, cr);
}
 }
 
@@ -1523,7 +1523,7 @@ int kvm_get_msr_common(struct kvm_vcpu *
break;
 #endif
default:
-   printk(KERN_ERR kvm: unhandled rdmsr: 0x%x\n, msr);
+   pr_guest(vcpu, unhandled rdmsr: 0x%x\n, msr);
return 1;
}
*pdata = data;
@@ -1575,11 +1575,11 @@ int kvm_set_msr_common(struct kvm_vcpu *
break;
 #endif
case MSR_IA32_MC0_STATUS:
-   printk(KERN_WARNING %s: MSR_IA32_MC0_STATUS 0x%llx, nop\n,
+   pr_guest(vcpu, %s: MSR_IA32_MC0_STATUS 0x%llx, nop\n,
   __FUNCTION__, data);
break;
case MSR_IA32_MCG_STATUS:
-   printk(KERN_WARNING %s: MSR_IA32_MCG_STATUS 0x%llx, nop\n,
+   pr_guest(vcpu, %s: MSR_IA32_MCG_STATUS 0x%llx, nop\n,
__FUNCTION__, data);
break;
case MSR_IA32_UCODE_REV:
@@ -1599,7 +1599,7 @@ int kvm_set_msr_common(struct kvm_vcpu *
return vcpu_register_para(vcpu, data);
 
default:
-   printk(KERN_ERR kvm: unhandled wrmsr: 0x%x\n, msr);
+   pr_guest(vcpu, unhandled 

Re: [kvm-devel] [RFC 0/8]KVM: swap out guest pages

2007-07-24 Thread Rusty Russell
On Tue, 2007-07-24 at 09:59 +0300, Avi Kivity wrote:
 However, you can probably work around that by not setting an rmap for
 the kernel mappings, and instead have the guest teach the host where the
 kernel page tables live.  You'd only be left with shared libraries,
 until the kernel can share page tables for them too.

Well, I already treat kernel mappings specially (effectively I know the
guest's PAGE_OFFSET): they're kept identical in all the 4 shadows, and
need explicit guest flushing.

Whether the guest shares (non-kernel) page tables or not, I will shadow
them dumb as separate page table pages the way things stand.  So, yes,
shared libs will be my main issue.  Address space randomization means I
can't even use a heuristic such as looking for the page at the same
address in other shadows.  I'll come up with something.

Anyway, virtio what I'm *supposed* to be doing today...

Thanks,
Rusty.



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [RFC 4/8]KVM: move gfn_to_page out of kmap/unmap pars

2007-07-24 Thread Avi Kivity
Shaohua Li wrote:
 gfn_to_page might sleep with swap support. Move it out of the kmap calls.

   

I'd like to apply this to the kvm.git master branch so we don't have to 
maintain it.  Was this tested on a highmem machine?  If not, I can do it.


-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] preclean up for live migration

2007-07-24 Thread Avi Kivity
Dong, Eddie wrote:
 Against lapic2

 This is a pre-cleanup for in kernel irqchip live migration support.
 A guest may not have APIC but still have apic_base_msr be
 save/restored in current live migration framework.


 Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]

 diff --git a/drivers/kvm/i8259.c b/drivers/kvm/i8259.c
 diff --git a/drivers/kvm/irq.h b/drivers/kvm/irq.h
 index a74d2e9..6cfc19f 100644
 --- a/drivers/kvm/irq.h
 +++ b/drivers/kvm/irq.h
 @@ -106,7 +106,6 @@ struct kvm_ioapic {
  struct kvm_lapic {
   spinlock_t lock;/* TODO for revise */
   u32 status;
 - u64 base_msr;
   unsigned long base_address;
   struct kvm_io_device dev;
   struct {
 diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
 index d7e16ba..e62ecf2 100644
 --- a/drivers/kvm/kvm.h
 +++ b/drivers/kvm/kvm.h   
 @@ -336,6 +336,7 @@ struct kvm_vcpu {
   unsigned long cr4;
   u64 pdptrs[4]; /* pae */
   u64 shadow_efer;
 + u64 apic_base_msr;
   

Can we keep the name the same?  Then this patch simply undoes some of 
the main lapic patch and we can fold them together.

-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] preview of in kernel irqchip live migration support

2007-07-24 Thread Avi Kivity
Dong, Eddie wrote:
 This patch is only for idea collection so far.
 The dilemma is that how to export the pic/IOAPIC/apic state data
 structure
 to user and make sure it has same/similar structure in user level.
 Otherwise a
 convert is a must and we must maintain the converter.

   

I think we have to have a converter, we can't tie the kernel to qemu or 
vice versa.

It's just a series of assignments, I don't see an issue with it.


 With this, PIC only guest can do live migration successfully. We can
 extend
 APIC side seamlessly.

 BTW, there is potential issue in IDT_Vectoring. The fix IMO is to retry
 vm_stop at user level
 to make sure no pending IDT_vectoring.
   

I agree.  How do we tell userspace we need to retry, though?  A field in 
kvm_run?  A field in the lapic state?

 Pls comments. Also I will temply off this week, Qing He may continue.

 Thx,eddie


 diff --git a/include/linux/kvm.h b/include/linux/kvm.h
 index 5307ba3..4eee80d 100644
 --- a/include/linux/kvm.h
 +++ b/include/linux/kvm.h
 @@ -51,6 +51,44 @@ struct kvm_irq_level {
   __u32 level;
  };
  
 +/* for KVM_GET_IRQCHIP / KVM_SET_IRQCHIP */
 +struct kvm_pic_state {
 + __u8 last_irr;  /* edge detection */
 + __u8 irr;   /* interrupt request register */
 + __u8 imr;   /* interrupt mask register */
 + __u8 isr;   /* interrupt service register */
 + __u8 priority_add;  /* highest irq priority */
 + __u8 irq_base;
 + __u8 read_reg_select;
 + __u8 poll;
 + __u8 special_mask;
 + __u8 init_state;
 + __u8 auto_eoi;
 + __u8 rotate_on_auto_eoi;
 + __u8 special_fully_nested_mode;
 + __u8 init4; /* true if 4 byte init */
 + __u8 elcr;  /* PIIX edge/trigger selection */
 + __u8 elcr_mask;
 + struct kvm_pic *pics_state;
 +};
   

You can't have this pointer in the userspace interface.

Also, please ensure that sizeof(struct kvm_pic_state) does not change in 
32/64 bit environments, since it gets embedded in the ioctl number.


-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH 1/2] kvm: Insist on a reason when injecting a #GP into a guest

2007-07-24 Thread Avi Kivity
Rusty Russell wrote:
 Insist on a reason when injecting a #GP into a guest

 All places but one already do a printk before injecting a #GP: just
 formalize it a little.

 Signed-off-by: Rusty Russell [EMAIL PROTECTED]

 diff -r f75b0a5fc387 drivers/kvm/kvm_main.c
 --- a/drivers/kvm/kvm_main.c  Mon Jul 23 11:16:12 2007 +1000
 +++ b/drivers/kvm/kvm_main.c  Mon Jul 23 16:59:56 2007 +1000
 @@ -419,8 +419,15 @@ static int kvm_vm_release(struct inode *
   return 0;
  }
  
 -static void inject_gp(struct kvm_vcpu *vcpu)
 -{
 +static void __attribute__((format(printf, 2, 3)))
 +inject_gp(struct kvm_vcpu *vcpu, const char *why_fmt, ...)
 +{
 + va_list args;
 +
 + va_start(args, why_fmt);
 + printk(KERN_DEBUG kvm: #GP );
 + vprintk(why_fmt, args);
 + va_end(args);
   kvm_arch_ops-inject_gp(vcpu, 0);
  }
   

Some guests (non hardware accelerated hypervisors, mostly) will generate 
#gp.  We'll want to inject exceptions without noise then.  I don't think 
we have such an exception today, but it's an excuse to have a clean 
__inject_gp() and a varargs-infested inject_gp().

  
 @@ -464,22 +471,21 @@ void set_cr0(struct kvm_vcpu *vcpu, unsi
  void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
  {
   if (cr0  CR0_RESERVED_BITS) {
 - printk(KERN_DEBUG set_cr0: 0x%lx #GP, reserved bits 0x%lx\n,
 -cr0, vcpu-cr0);
 - inject_gp(vcpu);
 + inject_gp(vcpu,
 +   set_cr0: 0x%lx reserved bits 0x%lx\n,
 +   cr0, vcpu-cr0);
   

Why three lines?

   return;
   }
  
   if ((cr0  X86_CR0_NW)  !(cr0  X86_CR0_CD)) {
 - printk(KERN_DEBUG set_cr0: #GP, CD == 0  NW == 1\n);
 - inject_gp(vcpu);
 + inject_gp(vcpu,
 +   set_cr0: CD == 0  NW == 1\n);
   return;
   

Are you deliberately ignoring an opportunity to reduce our line count?!

 @@ -1843,8 +1834,7 @@ int kvm_setup_pio(struct kvm_vcpu *vcpu,
   /*
* String I/O in reverse.  Yuck.  Kill the guest, fix later.
*/
 - printk(KERN_ERR kvm: guest string pio down\n);
 - inject_gp(vcpu);
 + inject_gp(vcpu, guest string pio down\n);
   return 1;
   }
   vcpu-run-io.count = now;
   

This one really wants to be a KERN_ERR.  It's not a guest exception, 
it's a kvm unimplemented feature for which the guest pays the price.  I 
guess a good place for __inject_gp().

-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

2007-07-24 Thread Avi Kivity
Rusty Russell wrote:
 If the guest can invoke a printk(), it can potentially flood the logs,
 causing a host DoS.  We should also indicate *which* guest we're
 talking about.

 This patch adds pr_guest (analogous to pr_debug) which ratelimits.
 Not all printk's were replaced: some are only printed once and others
 should probably be replaced by BUG().  I removed the kvm_printf in
 init_rmode_tss: it says nothing that the return value doesn't say.

 Coders should be aware that printing in the logs is not particularly
 useful except to give feedback to developers. ie. should not be used
 for chit-chat.

  int kvm_init_arch(struct kvm_arch_ops *ops, struct module *module);
  void kvm_exit_arch(void);
 diff -r 3f158ee9df43 drivers/kvm/kvm_main.c
 --- a/drivers/kvm/kvm_main.c  Tue Jul 24 16:22:39 2007 +1000
 +++ b/drivers/kvm/kvm_main.c  Tue Jul 24 16:28:33 2007 +1000
 @@ -425,8 +425,8 @@ inject_gp(struct kvm_vcpu *vcpu, const c
   va_list args;
  
   va_start(args, why_fmt);
 - printk(KERN_DEBUG kvm: #GP );
 - vprintk(why_fmt, args);
 + if (pr_guest(vcpu, #GP ))
 + vprintk(why_fmt, args);
   va_end(args);
   kvm_arch_ops-inject_gp(vcpu, 0);
  }
   

Why go through this optimization?  If it happens frequently, we can just 
remove the printk().  The printk()s are mostly on not-expected-to-happen 
exceptions, and should just be removed if guests do exercise them.


-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH 1/2] kvm: Insist on a reason when injecting a #GP into a guest

2007-07-24 Thread Rusty Russell
On Tue, 2007-07-24 at 13:15 +0300, Avi Kivity wrote:
 Rusty Russell wrote:
  +static void __attribute__((format(printf, 2, 3)))
  +inject_gp(struct kvm_vcpu *vcpu, const char *why_fmt, ...)
...
  kvm_arch_ops-inject_gp(vcpu, 0);
   }

 
 Some guests (non hardware accelerated hypervisors, mostly) will generate 
 #gp.  We'll want to inject exceptions without noise then.  I don't think 
 we have such an exception today, but it's an excuse to have a clean 
 __inject_gp() and a varargs-infested inject_gp().

I agree, except I never saw the point of a this wrapper anyway.  Is
there a good reason not to call kvm_arch_ops-inject_gp directly?

  @@ -464,22 +471,21 @@ void set_cr0(struct kvm_vcpu *vcpu, unsi
   void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
   {
  if (cr0  CR0_RESERVED_BITS) {
  -   printk(KERN_DEBUG set_cr0: 0x%lx #GP, reserved bits 0x%lx\n,
  -  cr0, vcpu-cr0);
  -   inject_gp(vcpu);
  +   inject_gp(vcpu,
  + set_cr0: 0x%lx reserved bits 0x%lx\n,
  + cr0, vcpu-cr0);

 
 Why three lines?

Erk, I deleted the #GP from these messages later.  Will fix.

  -   printk(KERN_ERR kvm: guest string pio down\n);
  -   inject_gp(vcpu);
  +   inject_gp(vcpu, guest string pio down\n);
  return 1;
  }
  vcpu-run-io.count = now;
 
 This one really wants to be a KERN_ERR.  It's not a guest exception, 
 it's a kvm unimplemented feature for which the guest pays the price.  I 
 guess a good place for __inject_gp().

Good point, by itself this patch is bad.  See 2/2.

Thanks,
Rusty.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH 1/2] kvm: Insist on a reason when injecting a #GP into a guest

2007-07-24 Thread Avi Kivity
Rusty Russell wrote:
 On Tue, 2007-07-24 at 13:15 +0300, Avi Kivity wrote:
   
 Rusty Russell wrote:
 
 +static void __attribute__((format(printf, 2, 3)))
 +inject_gp(struct kvm_vcpu *vcpu, const char *why_fmt, ...)
   
 ...
   
 kvm_arch_ops-inject_gp(vcpu, 0);
  }
   
   
 Some guests (non hardware accelerated hypervisors, mostly) will generate 
 #gp.  We'll want to inject exceptions without noise then.  I don't think 
 we have such an exception today, but it's an excuse to have a clean 
 __inject_gp() and a varargs-infested inject_gp().
 

 I agree, except I never saw the point of a this wrapper anyway.  Is
 there a good reason not to call kvm_arch_ops-inject_gp directly?

   

No.

 @@ -464,22 +471,21 @@ void set_cr0(struct kvm_vcpu *vcpu, unsi
  void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
  {
 if (cr0  CR0_RESERVED_BITS) {
 -   printk(KERN_DEBUG set_cr0: 0x%lx #GP, reserved bits 0x%lx\n,
 -  cr0, vcpu-cr0);
 -   inject_gp(vcpu);
 +   inject_gp(vcpu,
 + set_cr0: 0x%lx reserved bits 0x%lx\n,
 + cr0, vcpu-cr0);
   
   
 Why three lines?
 

 Erk, I deleted the #GP from these messages later.  Will fix.

   

No, inject_gp() adds that.



-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] [patch] mmu.c: remove unused functions

2007-07-24 Thread Nguyen Anh Quynh

This patch removes some unused functions in mmu.c

Signed-off-by: Nguyen Anh Quynh [EMAIL PROTECTED]
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index a7985b1..13fb6bb 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -156,21 +156,6 @@ static struct kmem_cache *pte_chain_cache;
 static struct kmem_cache *rmap_desc_cache;
 static struct kmem_cache *mmu_page_header_cache;
 
-static int is_write_protection(struct kvm_vcpu *vcpu)
-{
-	return vcpu-cr0  X86_CR0_WP;
-}
-
-static int is_cpuid_PSE36(void)
-{
-	return 1;
-}
-
-static int is_nx(struct kvm_vcpu *vcpu)
-{
-	return vcpu-shadow_efer  EFER_NX;
-}
-
 static int is_present_pte(unsigned long pte)
 {
 	return pte  PT_PRESENT_MASK;
@@ -181,11 +166,6 @@ static int is_writeble_pte(unsigned long pte)
 	return pte  PT_WRITABLE_MASK;
 }
 
-static int is_io_pte(unsigned long pte)
-{
-	return pte  PT_SHADOW_IO_MARK;
-}
-
 static int is_rmap_pte(u64 pte)
 {
 	return (pte  (PT_WRITABLE_MASK | PT_PRESENT_MASK))
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [patch] mmu.c: remove unused functions

2007-07-24 Thread Avi Kivity
Nguyen Anh Quynh wrote:
 This patch removes some unused functions in mmu.c

 -static int is_nx(struct kvm_vcpu *vcpu)
 -{
 - return vcpu-shadow_efer  EFER_NX;
 -}
 -

is_nx() for example, is used.

More care, please.


-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

2007-07-24 Thread Avi Kivity
Rusty Russell wrote:
 On Tue, 2007-07-24 at 13:19 +0300, Avi Kivity wrote:
   
 Rusty Russell wrote:
 
 diff -r 3f158ee9df43 drivers/kvm/kvm_main.c
 --- a/drivers/kvm/kvm_main.cTue Jul 24 16:22:39 2007 +1000
 +++ b/drivers/kvm/kvm_main.cTue Jul 24 16:28:33 2007 +1000
 @@ -425,8 +425,8 @@ inject_gp(struct kvm_vcpu *vcpu, const c
 va_list args;
  
 va_start(args, why_fmt);
 -   printk(KERN_DEBUG kvm: #GP );
 -   vprintk(why_fmt, args);
 +   if (pr_guest(vcpu, #GP ))
 +   vprintk(why_fmt, args);
 va_end(args);
 kvm_arch_ops-inject_gp(vcpu, 0);
  }
   
   
 Why go through this optimization?  If it happens frequently, we can just 
 remove the printk().  The printk()s are mostly on not-expected-to-happen 
 exceptions, and should just be removed if guests do exercise them.
 

 It's not an optimization, just being thorough.  It raises it to
 KERN_WARN and makes it a common format.  Importantly there should be no
 unlimited printks which can be triggered by the guest.

 KVM *will* be used to run malicious guests.  That's going to be hard to
 lock down later, so I figure we should start now.

There's no reason to make this KERN_WARN.  There's nothing wrong with 
the host, and there may not be anything wrong with the guest.  These are 
only used to see if the guest did something unexpected, which may or may 
not be a problem (a kvm test suite would certainly trigger them).

Perhaps we should make them conditional on a debug flag, or remove them 
completely.  Most of them don't ever trigger, and i don't expect we can 
bring up a new guest solely using these printks.


-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] KVM-33 + Windows Server 2003 = VMX-OK / SVM-kernel panic?

2007-07-24 Thread Alessandro Sardo
Hello list,

I am facing some big issues with the latest KVM release. I am still 
trying to boot and use the same VM image on four different hosts, but 
with outstanding bad luck.

More precisely, I created a brand new VM image and installed Windows 
Server 2003. Then, I did shut it down and archived it. After that, I  
copied it to the four hosts and tried to boot it, using the same KVM 
version and qemu command line.


Test #1
CPU model: 1 x Dual-Core Intel Core Duo
Host: Ubuntu 6.06, kernel 2.6.15
KVM-33
Result - everything is OK, no problems at all



Test #2
CPU model: 1 x Dual-Core Intel Core 2 Duo
Host: RHEL5 x86_64, kernel 2.6.18-8.1.8.el5
KVM-33
Result - everything is OK, no problems at all



Test #3
CPU model: 1 x Single-Core AMD Athlon64 Processor 3500+ AM2
Host: RHEL5 x86_64, kernel 2.6.18-8.1.8.el5
KVM-33
Result - boots fine, but when I try to install the SP2 I get the 
following kernel panic:

Unable to handle kernel NULL pointer dereference at  RIP:
[883d80ce] :kvm:x86_emulate_memop+0x2a79/0x3b03
PGD 7b8a067 PUD 3973067 PMD 0
Oops: 0002 [1] SMP
last sysfs file: /class/net/lo/ifindex
CPU 0
Modules linked in: kvm_amd(U) kvm(U) tun netconsole bridge 
cpufreq_ondemand video sbs i2c_ec button battery asus_acpi 
acpi_memhotplug ac lp snd_hda_intel snd_hda_codec snd_seq_dummy 
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss floppy 
snd_mixer_oss snd_pcm pcspkr sg i2c_nforce2 i2c_core snd_timer snd 
shpchp soundcore k8_edac snd_page_alloc parport_pc edac_mc forcedeth 
parport ide_cd cdrom serio_raw dm_snapshot dm_zero dm_mirror dm_mod 
sata_nv libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
Pid: 2168, comm: kvm Not tainted 2.6.18-8.1.8.el5 #1
RIP: 0010:[883d80ce] [883d80ce] 
:kvm:x86_emulate_memop+0x2a79/0x3b03
RSP: 0018:81006225d9d8 EFLAGS: 00010246
RAX:  RBX:  RCX: 0003
RDX: 81006225da60 RSI:  RDI: 81006207a130
RBP: 883df621 R08: 0200 R09: 
R10: 81003f18d000 R11: 883eb542 R12: 
R13: 81006225db78 R14:  R15: 
FS: ffdff000() GS:8038a000() knlGS:
CS: 0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 62cd7000 CR4: 06e0
Process kvm (pid: 2168, threadinfo 81006225c000, task 81007d987100)
Stack: 883df600 03007fffe0e1ce40 7fffe0e1cea0 03000140
81006225db00 0004 0004 0300
 0004 0004 
Call Trace:
[883eb542] :kvm_amd:svm_get_segment_base+0x0/0x5f
[883d5657] :kvm:x86_emulate_memop+0x2/0x3b03
[883d0e95] :kvm:emulate_instruction+0xee/0x278
[883eb542] :kvm_amd:svm_get_segment_base+0x0/0x5f
[883eacec] :kvm_amd:emulate_on_interception+0xf/0x30
[883ebbed] :kvm_amd:svm_vcpu_run+0x506/0x599
[883d11e4] :kvm:kvm_vcpu_ioctl+0x1c5/0xd04
[80044d31] try_to_wake_up+0x407/0x418
[800850ed] __wake_up_common+0x3e/0x68
[8002dd9b] __wake_up+0x38/0x4f
[800d8498] core_sys_select+0x234/0x265
[80093f38] __dequeue_signal+0x18b/0x19b
[80094fd2] dequeue_signal+0x3c/0xbc
[8003fc5a] do_ioctl+0x21/0x6b
[8002fa60] vfs_ioctl+0x248/0x261
[80058bf0] getnstimeofday+0x10/0x28
[8004a266] sys_ioctl+0x59/0x78
[8005b14e] system_call+0x7e/0x83


Code: 4c 89 00 eb 63 48 8b 94 24 f8 00 00 00 48 8b 84 24 08 01 00
RIP [883d80ce] :kvm:x86_emulate_memop+0x2a79/0x3b03
RSP 81006225d9d8
CR2: 
0Kernel panic - not syncing: Fatal exception


Test #4 (the most important one)
CPU model: 2 x Dual-Core AMD Opteron Processor 2210
Host: RHEL5 x86_64, kernel 2.6.18-8.1.8.el5
KVM-33
Result - boots fine, but I cannot get past logon - I type 
username/password and press enter, then I *always* get a BSOD (I sent a 
screenshot yesterday to the list)


This is driving me nuts. I can make the VM image available to anyone 
interested, please contact me privately for link and account details. 
Thanks,

AS


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

2007-07-24 Thread Rusty Russell
On Tue, 2007-07-24 at 14:01 +0300, Avi Kivity wrote:
 Rusty Russell wrote:
  KVM *will* be used to run malicious guests.  That's going to be hard to
  lock down later, so I figure we should start now.
 
 There's no reason to make this KERN_WARN.  There's nothing wrong with 
 the host, and there may not be anything wrong with the guest.  These are 
 only used to see if the guest did something unexpected, which may or may 
 not be a problem (a kvm test suite would certainly trigger them).
 
 Perhaps we should make them conditional on a debug flag, or remove them 
 completely.  Most of them don't ever trigger, and i don't expect we can 
 bring up a new guest solely using these printks.

So should there be two routines?  pr_unimpl() (KERN_ERR) and
pr_unexpected() (KERN_DEBUG) maybe.  Both ratelimited, with nice
formatting to tell user which machine  cpu for reporting when there's a
problem...

Turning them off is your call: have they proven useful?

Thanks,
Rusty.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] KVM-33 + Windows Server 2003 = VMX-OK / SVM-kernel panic?

2007-07-24 Thread Alexey Eremenko
Actually this is known problem, that I reproduced easily.

Windows 2000/XP/2003 (32-bit) all fails on AMD SVM.
Strage, but Vista runs on SVM fine.

VMX and SVM have different problems, with different guests failing on each.

-- 
-Alexey Eremenko Technologov

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] KVM-33 + Windows Server 2003 = VMX-OK / SVM-kernel panic?

2007-07-24 Thread Alexey Eremenko
http://sourceforge.net/tracker/index.php?func=detailaid=1750684group_id=180599atid=893831
http://sourceforge.net/tracker/index.php
bug 1750684

-- 
-Alexey Eremenko Technologov

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

2007-07-24 Thread Avi Kivity
Rusty Russell wrote:
 On Tue, 2007-07-24 at 14:01 +0300, Avi Kivity wrote:
   
 Rusty Russell wrote:
 
 KVM *will* be used to run malicious guests.  That's going to be hard to
 lock down later, so I figure we should start now.
   
 There's no reason to make this KERN_WARN.  There's nothing wrong with 
 the host, and there may not be anything wrong with the guest.  These are 
 only used to see if the guest did something unexpected, which may or may 
 not be a problem (a kvm test suite would certainly trigger them).

 Perhaps we should make them conditional on a debug flag, or remove them 
 completely.  Most of them don't ever trigger, and i don't expect we can 
 bring up a new guest solely using these printks.
 

 So should there be two routines?  pr_unimpl() (KERN_ERR) and
 pr_unexpected() (KERN_DEBUG) maybe.  Both ratelimited, with nice
 formatting to tell user which machine  cpu for reporting when there's a
 problem...

 Turning them off is your call: have they proven useful?
   

Unimplemented has certainly proven useful, mostly with msrs (which we 
implement on demand).

The unexpected ones are usually badly implemented (as you discovered 
with the set_cr4() bug), so if something goes wrong and they show up, 
that's a hint.  However, that was useful during initial bringup, and 
these things don't happen anymore, so it's probably better to remove 
them than to introduce a new kernel subsystem after a 400-message thread 
on kvm-devel.  They don't rhyme anyway.

-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] KVM-33 + Windows Server 2003 = VMX-OK / SVM-kernel panic?

2007-07-24 Thread Avi Kivity
Alessandro Sardo wrote:

One at a time.

 Test #3
 CPU model: 1 x Single-Core AMD Athlon64 Processor 3500+ AM2
 Host: RHEL5 x86_64, kernel 2.6.18-8.1.8.el5
 KVM-33
 Result - boots fine, but when I try to install the SP2 I get the 
 following kernel panic:

 Unable to handle kernel NULL pointer dereference at  RIP:
 [883d80ce] :kvm:x86_emulate_memop+0x2a79/0x3b03
 PGD 7b8a067 PUD 3973067 PMD 0
 Oops: 0002 [1] SMP
 last sysfs file: /class/net/lo/ifindex
 CPU 0
 Modules linked in: kvm_amd(U) kvm(U) tun netconsole bridge 
 cpufreq_ondemand video sbs i2c_ec button battery asus_acpi 
 acpi_memhotplug ac lp snd_hda_intel snd_hda_codec snd_seq_dummy 
 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss floppy 
 snd_mixer_oss snd_pcm pcspkr sg i2c_nforce2 i2c_core snd_timer snd 
 shpchp soundcore k8_edac snd_page_alloc parport_pc edac_mc forcedeth 
 parport ide_cd cdrom serio_raw dm_snapshot dm_zero dm_mirror dm_mod 
 sata_nv libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
 Pid: 2168, comm: kvm Not tainted 2.6.18-8.1.8.el5 #1
 RIP: 0010:[883d80ce] [883d80ce] 
 :kvm:x86_emulate_memop+0x2a79/0x3b03
 RSP: 0018:81006225d9d8 EFLAGS: 00010246
 RAX:  RBX:  RCX: 0003
 RDX: 81006225da60 RSI:  RDI: 81006207a130
 RBP: 883df621 R08: 0200 R09: 
 R10: 81003f18d000 R11: 883eb542 R12: 
 R13: 81006225db78 R14:  R15: 
 FS: ffdff000() GS:8038a000() knlGS:
 CS: 0010 DS:  ES:  CR0: 80050033
 CR2:  CR3: 62cd7000 CR4: 06e0
 Process kvm (pid: 2168, threadinfo 81006225c000, task 81007d987100)
 Stack: 883df600 03007fffe0e1ce40 7fffe0e1cea0 03000140
 81006225db00 0004 0004 0300
  0004 0004 
 Call Trace:
 [883eb542] :kvm_amd:svm_get_segment_base+0x0/0x5f
 [883d5657] :kvm:x86_emulate_memop+0x2/0x3b03
 [883d0e95] :kvm:emulate_instruction+0xee/0x278
 [883eb542] :kvm_amd:svm_get_segment_base+0x0/0x5f
 [883eacec] :kvm_amd:emulate_on_interception+0xf/0x30
 [883ebbed] :kvm_amd:svm_vcpu_run+0x506/0x599
 [883d11e4] :kvm:kvm_vcpu_ioctl+0x1c5/0xd04
 [80044d31] try_to_wake_up+0x407/0x418
 [800850ed] __wake_up_common+0x3e/0x68
 [8002dd9b] __wake_up+0x38/0x4f
 [800d8498] core_sys_select+0x234/0x265
 [80093f38] __dequeue_signal+0x18b/0x19b
 [80094fd2] dequeue_signal+0x3c/0xbc
 [8003fc5a] do_ioctl+0x21/0x6b
 [8002fa60] vfs_ioctl+0x248/0x261
 [80058bf0] getnstimeofday+0x10/0x28
 [8004a266] sys_ioctl+0x59/0x78
 [8005b14e] system_call+0x7e/0x83


 Code: 4c 89 00 eb 63 48 8b 94 24 f8 00 00 00 48 8b 84 24 08 01 00
 RIP [883d80ce] :kvm:x86_emulate_memop+0x2a79/0x3b03
 RSP 81006225d9d8
 CR2: 
 0Kernel panic - not syncing: Fatal exception
 
   

Can you post the output of 'objdump -Sr kernel/x86_emulate.o'?  Please 
ensure that it is exactly the same object used to generate this oops.

-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [RFC 4/8]KVM: move gfn_to_page out of kmap/unmap pars

2007-07-24 Thread Shaohua Li
2007/7/24, Avi Kivity [EMAIL PROTECTED]:
 Shaohua Li wrote:
  gfn_to_page might sleep with swap support. Move it out of the kmap calls.
 
 

 I'd like to apply this to the kvm.git master branch so we don't have to
 maintain it.  Was this tested on a highmem machine?  If not, I can do it.
My test system has 1G memory, so it should work. I only tested 32bit
system, better check a x64 build.

Thanks,
Shaohua

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] Host/Guest SMP: Looking for answers

2007-07-24 Thread Peter Meier
Hello,

I've heard that KVM-33 now supports SMP hosts and SMP guests,
which is cool. However I do have some newbie-level questions
about this one.

- I assume this is implemented by using n threads for n CPUs/CPU
  cores and letting the host OS schedule accordingly? Or does the
  VM somehow automagically bind each of its virtual CPU threads
  to one of the host CPUs/cores?

- I'd be interested to learn how to actually use SMP ;-). What
  options do I need to enable inside the guest kernel's menucon-
  fig beyond the basic SMP one, specifically what SMP sub-archi-
  tecture type?

- For that matter, which Processor Family option is appropriate
  inside KVM? I've been using Pentium III so far. Should I be
  using the family of the host system?

- How do I tell the VM to use multiple CPUs/cores? Some command
  line arguments to qemu-system-x86_64, or another way?


Thanks for reading,
Peter

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] (no subject)

2007-07-24 Thread Shaohua Li
 From: Avi Kivity [EMAIL PROTECTED]
 To: Li, Shaohua [EMAIL PROTECTED]
 Date: Tue, 24 Jul 2007 13:42:29 +0800
 Subject: Re: [RFC 0/8]KVM: swap out guest pages


 Shaohua Li wrote:
  On Mon, 2007-07-23 at 18:27 +0800, Avi Kivity wrote:
 
  Shaohua Li wrote:
 
  This patch series make kvm guest pages be able to be swapped out and
  dynamically allocated. Without it, all guest memory is allocated at
  guest start time.
 
  patches are against latest git, and you need first patch Avi's
 
  kvm-sch
 
  integration patch
 
 
 
 (http://sourceforge.net/mailarchive/forum.php?thread_name=11841693332609-git-send-email-avi%40qumranet.comforum_name=kvm-devel
 ).
 
  Patch is quite stable in my test. With the patch, I can run a 256M
  memory guest in a 300M memory host.
 
  What about the opposite?
 
 
  If guest is idle, the memory it used
  can be less than 10M. I did a simple performance test (measure
 
  kernel
 
  build time in guest), if there is few swap, the performance w/wo the
  patch difference isn't significent. If you have better measurement
  approach, please let me try.
 
  Unresolved issue:
  1. swapoff doesn't work, we need a hook.
  2. SMP guest might not work, as kvm doesn't support smp till now.
  3. better algorithm to select swaped out guest pages according to
  guest's memory usage.
  Maybe more.
 
  Any suggests and comments are appreciated.
 
 
  The big question is whether to have kvm's own address_space or not.
 
  Having an address_space (like your patch does) is remarkably simple,
  and
  requires few hooks from the current vm.  However using existing vmas
  mapped by the user has many advantages:
 
  - compatible with s390 requirements
  - allows the user to use hugetlbfs pages, which have a performance
  advantage using ept/npt (but which are unswappable)
  - allows the user to map a file (which can be regarded as way to
  specify
  the swap device)
  - better ingration with the rest of the vm
 
  I am quite torn between the simplicity of your approach and the
  advantages of using generic vmas.  However, s390 pretty much forces
  our
  hand.
 
  What is your opinion of extending generic vmas to back kvm guest
  memory?
 
  several issues:
  1. vma is to manage usersapce address, kvm guest uses full address
  space.
  2. qemu itself must use some address space.
 

 My idea is to keep the current slot concept, but instead of having kvm
 allocate pages for a slot, it would call get_user_pages() for a virtual
 address range.  Userspace doesn't directly talk about vmas, just virtual
 address ranges.
all the APIs need vma/page table handling. swap also needs vma for
rmap for generic file.

Thanks,
Shaohua

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Host/Guest SMP: Looking for answers

2007-07-24 Thread Avi Kivity
Peter Meier wrote:
 Hello,

 I've heard that KVM-33 now supports SMP hosts and SMP guests,
 which is cool. However I do have some newbie-level questions
 about this one.

 - I assume this is implemented by using n threads for n CPUs/CPU
   cores and letting the host OS schedule accordingly? Or does the
   VM somehow automagically bind each of its virtual CPU threads
   to one of the host CPUs/cores?
   

Every virtual cpu (vcpu) is mapped to a thread.  The scheduler maps 
threads to cores.  It's no different than running a normal multithreaded 
application.

 - I'd be interested to learn how to actually use SMP ;-). What
   options do I need to enable inside the guest kernel's menucon-
   fig beyond the basic SMP one, specifically what SMP sub-archi-
   tecture type?
   

Er, whichever you like.  At present, NUMA won't buy you anything, but 
that will change one day.  In general any smp-enabled kernel should 
work, and there's no reason to enable any fancy features.

 - For that matter, which Processor Family option is appropriate
   inside KVM? I've been using Pentium III so far. Should I be
   using the family of the host system?
   

P3 is a good choice, and so is using the host system.  I doubt it makes 
any measurable difference.

 - How do I tell the VM to use multiple CPUs/cores? Some command
   line arguments to qemu-system-x86_64, or another way?
   

Use the -smp N option as documented in the qemu help.


-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Host/Guest SMP: Looking for answers

2007-07-24 Thread Peter Meier
Thanks Avi :). Off to try it out ...


Regards,
Peter

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] compile error [u]

2007-07-24 Thread Andreas Jellinghaus [c]
kvm needs zlib development files to compile,
but does not probe for it in configure and does
not complain if they are missing.

a simple header check in qemu configure should
fix this.

Regards, Andreas

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Oops at boot - kernel 2.6.22.1

2007-07-24 Thread Fix
 Can you post the guest image (if it is free and has no private data)?

Here is the test case. Image contains kernel and bootloader: 
http://depositfiles.com/en/files/1304964


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] [PATCH] KVM: VMX cannot yet handle migration-after-preemption, so disable it

2007-07-24 Thread Gregory Haskins
This patch applies to the preempt-hooks branch to enable KVM to function
properly on VMX.  With preemption enabled, the KVM context can get scheduled
out at arbitrary points.  The preempt-hooks allow us to correctly restore
the host state while being preemptible, but preemption causes problems on the
schedule-in side if the vcpu-task migrates to a new pCPU.

Ideally we can handle the migration scenario better (patch for this in
progress).  However, this patch provides correctness in the interim at the
expense of a small amount of flexibility. E.g. we can only migrate when the
vcpu_lock is not held.

Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---

 drivers/kvm/kvm.h  |1 +
 drivers/kvm/kvm_main.c |3 +++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 03f374e..d18537c 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -318,6 +318,7 @@ struct kvm_vcpu {
struct vcpu_svm *svm;
};
struct mutex mutex;
+   cpumask_t cpumask;
int   cpu;
int   launched;
u64 host_tsc;
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index ef67572..4a19f6f 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -245,6 +245,8 @@ static void vcpu_load(struct kvm_vcpu *vcpu)
 
mutex_lock(vcpu-mutex);
cpu = get_cpu();
+   vcpu-cpumask = current-cpus_allowed;
+   set_cpus_allowed(current, cpumask_of_cpu(cpu));
preempt_hook_register(vcpu-preempt_hook);
kvm_arch_ops-vcpu_load(vcpu, cpu);
put_cpu();
@@ -255,6 +257,7 @@ static void vcpu_put(struct kvm_vcpu *vcpu)
preempt_disable();
kvm_arch_ops-vcpu_put(vcpu);
preempt_hook_unregister(vcpu-preempt_hook);
+   set_cpus_allowed(current, vcpu-cpumask);
preempt_enable();
mutex_unlock(vcpu-mutex);
 }


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Fwd: Re: kvm-31 seg fault

2007-07-24 Thread Gregory Haskins
On Tue, 2007-07-24 at 22:02 +, Chris Clayton wrote:

 
 I've been doing some more digging around here and thought I'd report my 
 findings. I've found that under kvm 31 and 33, qemu-system-x86_64 always 
 fails with a seg fault when the (__thread) variable vcpu_env (declared at 
 line 33 of qemu-kvm.c) is accessed in kvm_update_interrupt_request(). I've 
 inserted useless statements (printf()s and assignments) at the head of the 
 function, and always get the seg fault at the first access to the variable.
 
 I'm building qemu with gcc-3.4.6, but to eliminate a fault in that compiler, 
 I've also built the application on my laptop with gcc-3.3.6 and copied the 
 binary over to my desktop machine. I still get the seg fault.
 
 Sorry if this is just noise on your line, but I thought I'd send it just in 
 case it's useful.

If you can, run your failing setup under valgrind.  Its great for
finding stuff like that.

Regards,
-Greg



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] KVM 29: Page fault in kernel mode while booting GNU/kFreeBSD

2007-07-24 Thread Aurelien Jarno
On Fri, Jul 20, 2007 at 09:57:55AM +0300, Avi Kivity wrote:
 Avi Kivity wrote:
  Please tell me what I can do to help debugging this problem. 
  Alternatively I have uploaded an image to reproduce the problem here:
  http://temp.aurel32.net/kfreebsd-amd64.img.g
  
 
  I've downloaded the image and booted it three times using kvm HEAD. 
  Each time I got to the login prompt.
 
  Is this always reproducible?  Can you check with kvm HEAD (not that I
  think of anything that could have fixed this).
 

 
 Sorry, that was on Intel.  It reproduces easily on AMD.

By comparing the cases were the old and the new condition are different,
I have found that the problem occurs for the lmsw and smsw instructions.

The patch below is very ugly, but it workarounds the problem.

diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 21ce977..6c1523f 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1206,11 +1206,13 @@ twobyte_insn:
goto cannot_emulate;
*(u16 *)_regs[modrm_rm]
= realmode_get_cr(ctxt-vcpu, 0);
+   no_wb = 1;
break;
case 6: /* lmsw */
if (modrm_mod != 3)
goto cannot_emulate;
realmode_lmsw(ctxt-vcpu, (u16)modrm_val, _eflags);
+   no_wb = 1;
break;
case 7: /* invlpg*/

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [patch] mmu.c: remove unused functions

2007-07-24 Thread Avi Kivity
Nguyen Anh Quynh wrote:
 On 7/24/07, Avi Kivity [EMAIL PROTECTED] wrote:
 Nguyen Anh Quynh wrote:
  This patch removes some unused functions in mmu.c

  -static int is_nx(struct kvm_vcpu *vcpu)
  -{
  - return vcpu-shadow_efer  EFER_NX;
  -}
  -

 is_nx() for example, is used.

 More care, please.

 Oops, I looked again. The way we handle static functions with
 paging_tmpl.h is weird.

 How about moving these functions there?

It's wierder than you think.  You'll get multiple definition errors.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] KVM 29: Page fault in kernel mode while booting GNU/kFreeBSD

2007-07-24 Thread Avi Kivity
Aurelien Jarno wrote:
 On Fri, Jul 20, 2007 at 09:57:55AM +0300, Avi Kivity wrote:
   
 Avi Kivity wrote:
 
 Please tell me what I can do to help debugging this problem. 
 Alternatively I have uploaded an image to reproduce the problem here:
 http://temp.aurel32.net/kfreebsd-amd64.img.g
 
 
 I've downloaded the image and booted it three times using kvm HEAD. 
 Each time I got to the login prompt.

 Is this always reproducible?  Can you check with kvm HEAD (not that I
 think of anything that could have fixed this).

   
   
 Sorry, that was on Intel.  It reproduces easily on AMD.
 

 By comparing the cases were the old and the new condition are different,
 I have found that the problem occurs for the lmsw and smsw instructions.
   

Ah, I was looking at amd-specific instructions (vmx decodes lmsw) but
missed these two.  Good work.

 The patch below is very ugly, but it workarounds the problem.
   

It's not ugly, it just lives in an ugly function.  But it does lack a
changelog and a signoff.

As to the ugliness, prehaps no_wb should be part of the opcode
descriptor bitmask (opcode_table and friend).

 diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
 index 21ce977..6c1523f 100644
 --- a/drivers/kvm/x86_emulate.c
 +++ b/drivers/kvm/x86_emulate.c
 @@ -1206,11 +1206,13 @@ twobyte_insn:
   goto cannot_emulate;
   *(u16 *)_regs[modrm_rm]
   = realmode_get_cr(ctxt-vcpu, 0);
 + no_wb = 1;
   break;
   case 6: /* lmsw */
   if (modrm_mod != 3)
   goto cannot_emulate;
   realmode_lmsw(ctxt-vcpu, (u16)modrm_val, _eflags);
 + no_wb = 1;
   break;
   case 7: /* invlpg*/

   


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] kvm-31 configure file bug

2007-07-24 Thread Avi Kivity
Simon Gao wrote:
 Avi Kivity wrote:
   
 Simon Gao wrote:
 
 So from kvm-31 and on, qemu command will become qemu-system-x86_64 no
 matter host system is 32bit or 64bit?  So it's possible to compile 64bit
 kvm qemu with only 32bit libraries?

   
   
 Yes and yes.  That's even more true for upstream qemu as well -- you
 can run a 64-bit guest on a non-64-bit capable cpu.

 
 I still had to change x86_64 to i386 in configure file. If I don't,
 then guest os will hang after initial boot image splash. This happened
 to kvm-31, kvm-32, kvm-33. The guest OSes worked fine with kvm-28.

 Is there some parameter I should pass to make? or when I start guest OS
 using qemu-system_x86_64 under 32bit Linux?

   

It should just work.  Is there anything in dmesg when the guest hangs? 
What guest is that?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH] KVM: VMX cannot yet handle migration-after-preemption, so disable it

2007-07-24 Thread Avi Kivity
Gregory Haskins wrote:
 This patch applies to the preempt-hooks branch to enable KVM to function
 properly on VMX.  With preemption enabled, the KVM context can get scheduled
 out at arbitrary points.  The preempt-hooks allow us to correctly restore
 the host state while being preemptible, but preemption causes problems on the
 schedule-in side if the vcpu-task migrates to a new pCPU.

 Ideally we can handle the migration scenario better (patch for this in
 progress).  However, this patch provides correctness in the interim at the
 expense of a small amount of flexibility. E.g. we can only migrate when the
 vcpu_lock is not held.

   

I'd rather wait for the real fix, especially as this is an experimental
branch.  Can you provide details of the issue?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Fwd: Re: kvm-31 seg fault

2007-07-24 Thread Avi Kivity
Chris Clayton wrote:
 Forgot to cc this to the list, sorry
 --  Forwarded Message  --

 Subject: Re: [kvm-devel] kvm-31 seg fault
 Date: Tuesday 24 July 2007
 From: Chris Clayton [EMAIL PROTECTED]
 To: Avi Kivity [EMAIL PROTECTED]

 Hi again Avi,

 On Sunday 22 July 2007, you wrote:
   
 Chris Clayton wrote:
 
 On Sunday 22 July 2007, you wrote:
   
 Chris Clayton wrote:
 
 Hi,

 I'm getting a seg fault running kvm-31 on linux-2.6.22.1-cfs-v19 and
 linux-2.6.22-git17.

 If I use the kvm-31 kernel modules with qemu from kvm-29, all is OK
 Also, running non-kvm guests, such as Windows ME, works fine with
 kvm-31.

 I have an strace log but its over 99 Kilobytes, so I haven't attached
 it to this mail. More than happy to compress it and send it by private
 mail, if required.

 I'm not subscribed, so please cc me.
   
 Please send it to me.  What guest are you running?  Is the host 32-bit
 or 64-bit?
 
 Attached is the log from 2.6.22-git17

 The host is 32bit and the guest is freebsd-6.2 although I get the same
 seg fault with slackware 10.2 and damn small linux 3.1 (all 32 bit).
   
 Unfortunately that doesn't help.  Can you generate a core ('ulimit -c
 unlimited' may help) and get a stacktrace from gdb?
 

 I've been doing some more digging around here and thought I'd report my 
 findings. I've found that under kvm 31 and 33, qemu-system-x86_64 always 
 fails with a seg fault when the (__thread) variable vcpu_env (declared at 
 line 33 of qemu-kvm.c) is accessed in kvm_update_interrupt_request(). I've 
 inserted useless statements (printf()s and assignments) at the head of the 
 function, and always get the seg fault at the first access to the variable.

 I'm building qemu with gcc-3.4.6, but to eliminate a fault in that compiler, 
 I've also built the application on my laptop with gcc-3.3.6 and copied the 
 binary over to my desktop machine. I still get the seg fault.
   

What's the host distro and glibc version?  Perhaps they're too old to
support __thread?


 Sorry if this is just noise on your line, but I thought I'd send it just in 
 case it's useful.

   

It isn't noise, this is helping us getting kvm better.



-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] [PATCH] load_pdptrs cleanups

2007-07-24 Thread Rusty Russell
load_pdptrs can be handed an invalid cr3, and it should not oops.
This can happen because we injected #gp in set_cr3() after we set
vcpu-cr3 to the invalid value, or from kvm_vcpu_ioctl_set_sregs(), or
possibly (?) memory configuration changes after the guest did
set_cr3().

We should also copy the pdpte array once, before checking and
assigning, otherwise an SMP guest can potentially alter the values
between the check and the set.

Finally one nitpick: ret = 1 should be done as late as possible: this
allows GCC to check for unset ret should the function change in
future.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r 98f010081c9f drivers/kvm/kvm_main.c
--- a/drivers/kvm/kvm_main.cWed Jul 25 10:39:07 2007 +1000
+++ b/drivers/kvm/kvm_main.cWed Jul 25 13:03:22 2007 +1000
@@ -432,30 +432,32 @@ static int load_pdptrs(struct kvm_vcpu *
gfn_t pdpt_gfn = cr3  PAGE_SHIFT;
unsigned offset = ((cr3  (PAGE_SIZE-1))  5)  2;
int i;
-   u64 pdpte;
u64 *pdpt;
int ret;
struct page *page;
+   u64 pdpte[ARRAY_SIZE(vcpu-pdptrs)];
 
spin_lock(vcpu-kvm-lock);
page = gfn_to_page(vcpu-kvm, pdpt_gfn);
-   /* FIXME: !page - emulate? 0xff? */
+   if (!page) {
+   ret = 0;
+   goto out;
+   }
+
pdpt = kmap_atomic(page, KM_USER0);
-
+   memcpy(pdpte, pdpt+offset, sizeof(pdpte));
+   kunmap_atomic(pdpt, KM_USER0);
+
+   for (i = 0; i  ARRAY_SIZE(pdpte); ++i) {
+   if ((pdpte[i]  1)  (pdpte[i]  0xfff001e6ull)) {
+   ret = 0;
+   goto out;
+   }
+   }
ret = 1;
-   for (i = 0; i  4; ++i) {
-   pdpte = pdpt[offset + i];
-   if ((pdpte  1)  (pdpte  0xfff001e6ull)) {
-   ret = 0;
-   goto out;
-   }
-   }
-
-   for (i = 0; i  4; ++i)
-   vcpu-pdptrs[i] = pdpt[offset + i];
-
+
+   memcpy(vcpu-pdptrs, pdpte, sizeof(vcpu-pdptrs));
 out:
-   kunmap_atomic(pdpt, KM_USER0);
spin_unlock(vcpu-kvm-lock);
 
return ret;



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] [ kvm-Bugs-1760056 ] OpenSolaris crashes kvm due to unhandled vm_exit

2007-07-24 Thread SourceForge.net
Bugs item #1760056, was opened at 2007-07-24 21:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=1760056group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kucharsk (kucharsk)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenSolaris crashes kvm due to unhandled vm_exit

Initial Comment:
When attempting a text console install of OpenSolaris, once the proper options 
are selected and the installation of the system is started, kvm crashes shortly 
thereafter with an unhandled vm_exit:

unhandled vm exit:  0xb897f
rax 000b rbx fec1fff0 rcx  rdx 
0029
rsi d389d200 rdi d389d400 rsp d38bcd40 rbp 
d38bcddc
r8   r9   r10  r11 

r12  r13  r14  r15 

rip fe832106 rflags 0202
cs 0158 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 0 avl 0)
ds 0160 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
es 0160 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
ss 0160 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
fs  (/000f p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
gs 01b0 (fec1fff0/06b7 p 1 dpl 0 db 1 s 1 type 3 l 0 g 0 avl 0)
tr 0150 (fec21370/0067 p 1 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0)
ldt  (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
gdt fe7fe000/2cf
idt fec206b0/7ff
cr0 29 cr2 d12ed8c3 cr3 baba020 cr4 6b8 cr8 0 efer 800
Aborted

This is with kvm-31 running on x86_64 kernel 2.6.22.1-27.fc7.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=1760056group_id=180599

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH] KVM: VMX cannot yet handle migration-after-preemption, so disable it

2007-07-24 Thread Gregory Haskins
On Wed, 2007-07-25 at 06:20 +0300, Avi Kivity wrote:

 
 I'd rather wait for the real fix, especially as this is an experimental
 branch.  Can you provide details of the issue?
 

Sure.  Keep in mind I am working with the RT kernel, so things might be
tighter and/or different than the vanilla kernel w.r.t. what I am about
to say:

But in a nutshell, the current code calls vcpu_clear() during a sched-in
operation.  If the vcpu is simply uninitialized, no problem.  We clear
it inline in the handler.  However, if the vcpu is migrating we have an
issue.  A synchronous smp_call_function_single() is invoked to
vcpu_clear the remote pCPU, but you must have interrupts enabled to call
this function to avoid a deadlock in the IPI handshake.  sched-in()
handlers are (and should be) called with interrupts and preemption
disabled. 

One solution is the one in which I provided already: Hobble migration
while the vcpu is locked.  Not very elegant, but it works.

Another solution (of which I am very close to getting working now) still
allows for a high degree of preemption _and_ migration.  It accomplishes
this by essentially deferring the migration to a workqueue and taking
itself off the run-queue all from inside the sched-in handler.  This is
all very tricky since the sched-X handlers are more or less like IRQ
context, but I think I have a suitable solution.  Stay tuned.

Regards,
-Greg


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH] KVM: VMX cannot yet handle migration-after-preemption, so disable it

2007-07-24 Thread Gregory Haskins
On Wed, 2007-07-25 at 07:13 +0300, Avi Kivity wrote:

 
 Preemption disabled yes, but interrupts? 

How do you think I found this? ;)

From smp_call_function_single in -rt:

WARN_ON(irqs_disabled());



 IIRC I picked the place where
 sched_in is called to have interrupts enabled, but maybe -rt changes
 that.

Perhaps...I haven't investigated what vanilla does.


   Seems like finding a better position for that hook would solve
 the problem.

I looked and there didn't appear to be a better place.  At the point
interrupts are restored we were well beyond the context_switch code and
it got plain ugly.  Maybe I should look again.

It may be moot, as I believe I am past the problem of getting the
VMCLEAR operation done on the owning pCPU.  Now I am wrestling with that
issue that I mentioned on IRC:  Problems actually using a migrated
context once we get scheduled back in.  Stay tuned.

-Greg



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel