[kvm-devel] [ kvm-Bugs-1874203 ] qemu-kvm gives just black screen

2008-05-11 Thread SourceForge.net 
Bugs item #1874203, was opened at 2008-01-18 01:14
Message generated for change (Settings changed) made by avik
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1874203&group_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: qemu
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Y-Chromosome (y-chromosome)
Assigned to: Nobody/Anonymous (nobody)
Summary: qemu-kvm gives just black screen

Initial Comment:
kernel 2.6.24-rc6
qemu 0.9.1
kvm 58 / 59 tested

i get just a black screen in the qemu window
if i try to start my windows 98 version with qemu-kvm
if i try it to start without it works flawlessly but slow.



--

Comment By: Emmanuel Florac (eflorac)
Date: 2008-01-23 20:17

Message:
Logged In: YES 
user_id=546391
Originator: NO

It works OK with version 60.

--

Comment By: Emmanuel Florac (eflorac)
Date: 2008-01-23 18:23

Message:
Logged In: YES 
user_id=546391
Originator: NO

Looks like a known bug, according to 
http://sourceforge.net/mailarchive/message.php?msg_name=477CB781.8090302%40qumranet.com

I'm trying kvm 60...

--

Comment By: Emmanuel Florac (eflorac)
Date: 2008-01-23 17:41

Message:
Logged In: YES 
user_id=546391
Originator: NO

Same problem. Running linux 2.6.22.16 amd64, kvm 059. The command line  I
use:

 qemu-system-x86_64 -m 384 -hda image.vmdk -boot c -s

With the -no-kvm option it works fine, but it freezes with kvm.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1874203&group_id=180599

-
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] [RFC] [VTD][patch 1/3] vt-d support for pci passthrough: kvm-vtd--kernel.patch

2008-05-11 Thread Muli Ben-Yehuda 
On Mon, May 05, 2008 at 02:36:23PM -0700, Kay, Allen M wrote:

> + for (j = 0; j < npages; j++) {
> + gpa +=  PAGE_SIZE;
> + page = gfn_to_page(kvm, gpa >> PAGE_SHIFT);
> + hpa = page_to_phys(page);
> + domain_page_mapping(kvm->arch.domain, gpa, hpa,
> PAGE_SIZE,
> + DMA_PTE_READ | DMA_PTE_WRITE);
> + vma = find_vma(current->mm, gpa);
> + if (!vma)
> + return 1;
> + write = (vma->vm_flags & VM_WRITE) != 0;
> + get_user_pages(current, current->mm, gpa,
> + PAGE_SIZE, write, 0, NULL, NULL);
> + }
> + return 0;
> +}

get_user_pages can fail. We should first try to fault in the pages and
only if succesfull map them in the IOMMU. Also, you need to protect
against the vma going away here.

Cheers,
Muli

-
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

[kvm-devel] [ kvm-Bugs-1959950 ] Fails to restore guests in real mode.

2008-05-11 Thread SourceForge.net 
Bugs item #1959950, was opened at 2008-05-08 04:45
Message generated for change (Comment added) made by avik
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959950&group_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: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: yunfeng (yunfeng)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to restore guests in real mode.

Initial Comment:
If save and restore a guest in real mode, for example guest running in grub or 
memtest86 program, the guest will crash.
The error message:
[EMAIL PROTECTED] results]# qemu-system-x86_64  -m 256 -net 
nic,macaddr=00:16:3e:10:4d:f1,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup 
-hda /share/xvs/var/tmp-img_gtp12_1210169969_1 -cdrom /root/memtest86-3.4a.iso 
-boot d -incoming file:///tmp/abc
unhandled vm exit: 0x8021 vcpu_id 0
rax 00e4 rbx 0001a8c0 rcx  rdx 
0020
rsi 0001c8dc rdi 0022 rsp 0001b880 rbp 
0001
r8   r9   r10  r11 

r12  r13  r14  r15 

rip 6069 rflags 00010002
cs 0010 (/ p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0)
ds 0018 (/ p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0)
es 0018 (/ p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0)
ss 0018 (/ p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0)
fs 0018 (/ p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0)
gs 0018 (/ p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0)
tr  (/ 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 25b4/2f
idt 250c/9f
cr0 11 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
Aborted


--

>Comment By: Avi Kivity (avik)
Date: 2008-05-11 13:35

Message:
Logged In: YES 
user_id=539971
Originator: NO

commit 662beb8baa37481d1cb32aff8354c931f8a73441
Author: Avi Kivity <[EMAIL PROTECTED]>
Date:   Sun May 11 13:34:46 2008 +0300

kvm: qemu: remove hacking the segment attributes on reset

The hack also corrupts the segment attributes on nonpaging
save/restore, which
is bad.  The previous commit fixes the problem at the source,
rendering the
hack unnecessary.

Fixes 1959950.

Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959950&group_id=180599

-
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

[kvm-devel] Yes the size makes the (super)man

2008-05-11 Thread julien 
Nick Cannon attributed his courting skills to us http://www.bualken.com/

-
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] performance with guests running 2.4 kernels (specifically RHEL3)

2008-05-11 Thread Avi Kivity 

Avi Kivity wrote:


I asked fo this thinking bypass_guest_pf may help show more 
information.  But thinking a bit more, it will not.


I think I do know what the problem is.  I will try it out.  Is there a 
free clone (like centos) available somewhere?


This patch tracks down emulated accesses to speculated ptes and marks 
them as accessed, preventing the flooding on centos-3.1.  Unfortunately 
it also causes a host oops midway through the boot process.


I believe the oops is merely exposed by the patch, not caused by it.

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

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 3d769c3..8c1e7f3 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1127,8 +1127,10 @@ unshadowed:
 		else
 			kvm_release_pfn_clean(pfn);
 	}
-	if (!ptwrite || !*ptwrite)
+	if (speculative) {
 		vcpu->arch.last_pte_updated = shadow_pte;
+		vcpu->arch.last_pte_gfn = gfn;
+	}
 }
 
 static void nonpaging_new_cr3(struct kvm_vcpu *vcpu)
@@ -1674,6 +1676,17 @@ static void mmu_guess_page_from_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
 	vcpu->arch.update_pte.pfn = pfn;
 }
 
+static void kvm_mmu_access_page(struct kvm_vcpu *vcpu, gfn_t gfn)
+{
+	u64 *spte = vcpu->arch.last_pte_updated;
+
+	if (spte
+	&& vcpu->arch.last_pte_gfn == gfn
+	&& shadow_accessed_mask
+	&& !(*spte & shadow_accessed_mask))
+		set_bit(PT_ACCESSED_SHIFT, spte);
+}
+
 void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
 		   const u8 *new, int bytes)
 {
@@ -1697,13 +1710,14 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
 	pgprintk("%s: gpa %llx bytes %d\n", __func__, gpa, bytes);
 	mmu_guess_page_from_pte_write(vcpu, gpa, new, bytes);
 	spin_lock(&vcpu->kvm->mmu_lock);
+	kvm_mmu_access_page(vcpu, gfn);
 	kvm_mmu_free_some_pages(vcpu);
 	++vcpu->kvm->stat.mmu_pte_write;
 	kvm_mmu_audit(vcpu, "pre pte write");
 	if (gfn == vcpu->arch.last_pt_write_gfn
 	&& !last_updated_pte_accessed(vcpu)) {
 		++vcpu->arch.last_pt_write_count;
-		if (vcpu->arch.last_pt_write_count >= 3)
+		if (vcpu->arch.last_pt_write_count >= 4)
 			flooded = 1;
 	} else {
 		vcpu->arch.last_pt_write_gfn = gfn;
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 1730757..258e5d5 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -15,7 +15,8 @@
 #define PT_USER_MASK (1ULL << 2)
 #define PT_PWT_MASK (1ULL << 3)
 #define PT_PCD_MASK (1ULL << 4)
-#define PT_ACCESSED_MASK (1ULL << 5)
+#define PT_ACCESSED_SHIFT 5
+#define PT_ACCESSED_MASK (1ULL << PT_ACCESSED_SHIFT)
 #define PT_DIRTY_MASK (1ULL << 6)
 #define PT_PAGE_SIZE_MASK (1ULL << 7)
 #define PT_PAT_MASK (1ULL << 7)
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 1d8cd01..0bdb392 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -242,6 +242,7 @@ struct kvm_vcpu_arch {
 	gfn_t last_pt_write_gfn;
 	int   last_pt_write_count;
 	u64  *last_pte_updated;
+	gfn_t last_pte_gfn;
 
 	struct {
 		gfn_t gfn;	/* presumed gfn during guest pte update */
-
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] performance with guests running 2.4 kernels (specifically RHEL3)

2008-05-11 Thread Avi Kivity 

Avi Kivity wrote:

Avi Kivity wrote:


I asked fo this thinking bypass_guest_pf may help show more 
information.  But thinking a bit more, it will not.


I think I do know what the problem is.  I will try it out.  Is there 
a free clone (like centos) available somewhere?


This patch tracks down emulated accesses to speculated ptes and marks 
them as accessed, preventing the flooding on centos-3.1.  
Unfortunately it also causes a host oops midway through the boot process.


I believe the oops is merely exposed by the patch, not caused by it.



It was caused by the patch, please try the updated one attached.

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

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 3d769c3..012e8ad 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1127,8 +1127,10 @@ unshadowed:
 		else
 			kvm_release_pfn_clean(pfn);
 	}
-	if (!ptwrite || !*ptwrite)
+	if (speculative) {
 		vcpu->arch.last_pte_updated = shadow_pte;
+		vcpu->arch.last_pte_gfn = gfn;
+	}
 }
 
 static void nonpaging_new_cr3(struct kvm_vcpu *vcpu)
@@ -1674,6 +1676,18 @@ static void mmu_guess_page_from_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
 	vcpu->arch.update_pte.pfn = pfn;
 }
 
+static void kvm_mmu_access_page(struct kvm_vcpu *vcpu, gfn_t gfn)
+{
+	u64 *spte = vcpu->arch.last_pte_updated;
+
+	if (spte
+	&& vcpu->arch.last_pte_gfn == gfn
+	&& shadow_accessed_mask
+	&& !(*spte & shadow_accessed_mask)
+	&& is_shadow_present_pte(*spte))
+		set_bit(PT_ACCESSED_SHIFT, spte);
+}
+
 void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
 		   const u8 *new, int bytes)
 {
@@ -1697,13 +1711,14 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
 	pgprintk("%s: gpa %llx bytes %d\n", __func__, gpa, bytes);
 	mmu_guess_page_from_pte_write(vcpu, gpa, new, bytes);
 	spin_lock(&vcpu->kvm->mmu_lock);
+	kvm_mmu_access_page(vcpu, gfn);
 	kvm_mmu_free_some_pages(vcpu);
 	++vcpu->kvm->stat.mmu_pte_write;
 	kvm_mmu_audit(vcpu, "pre pte write");
 	if (gfn == vcpu->arch.last_pt_write_gfn
 	&& !last_updated_pte_accessed(vcpu)) {
 		++vcpu->arch.last_pt_write_count;
-		if (vcpu->arch.last_pt_write_count >= 3)
+		if (vcpu->arch.last_pt_write_count >= 5)
 			flooded = 1;
 	} else {
 		vcpu->arch.last_pt_write_gfn = gfn;
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 1730757..258e5d5 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -15,7 +15,8 @@
 #define PT_USER_MASK (1ULL << 2)
 #define PT_PWT_MASK (1ULL << 3)
 #define PT_PCD_MASK (1ULL << 4)
-#define PT_ACCESSED_MASK (1ULL << 5)
+#define PT_ACCESSED_SHIFT 5
+#define PT_ACCESSED_MASK (1ULL << PT_ACCESSED_SHIFT)
 #define PT_DIRTY_MASK (1ULL << 6)
 #define PT_PAGE_SIZE_MASK (1ULL << 7)
 #define PT_PAT_MASK (1ULL << 7)
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 1d8cd01..0bdb392 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -242,6 +242,7 @@ struct kvm_vcpu_arch {
 	gfn_t last_pt_write_gfn;
 	int   last_pt_write_count;
 	u64  *last_pte_updated;
+	gfn_t last_pte_gfn;
 
 	struct {
 		gfn_t gfn;	/* presumed gfn during guest pte update */
-
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] KVM: kvm_vcpu_block task state race

2008-05-11 Thread Avi Kivity 
Marcelo Tosatti wrote:
> On Fri, May 09, 2008 at 04:22:08PM -0300, Marcelo Tosatti wrote:
>   
>> For things like register dumps I don't believe its worthwhile. Much
>> simpler to stop the vcpu with SIG_IPI, retrieve registers, and run it
>> again (now that you mention the busy-spin, it is broken right now, if a
>> vcpu is spinning without exiting to userspace).
>> 
>
> ... which is what Jan's gdb/monitor patch does.
>   

We'd better change it.  Suppose your vcpu is spinning, and you want to 
find out why?

One nice thing would be to add an on_vcpu(void (*func)(void *data), void 
*data), so that people don't have to open-code it for things like this.  
I tried to do this once, but backed off due to the mess that qemu-kvm 
threading was at the time.  I think it's much better off now.

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


-
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] KVM: kvm_vcpu_block task state race

2008-05-11 Thread Avi Kivity 
Marcelo Tosatti wrote:
>> The best practice is to issue all vcpu ioctls from the thread that 
>> created the vcpu; this becomes mandatory if we ever switch to a syscall 
>> interface and remove the mutex.
>> 
>
> For things like register dumps I don't believe its worthwhile. Much
> simpler to stop the vcpu with SIG_IPI, retrieve registers, and run it
> again (now that you mention the busy-spin, it is broken right now, if a
> vcpu is spinning without exiting to userspace).
>
> So do you want to give wait_event_interruptible() a try or wait for that
> change until userspace never issues vcpu ioctl's to a possibly busy vcpu
> (and go with the patch above)?
>   

Do we have anything critical that issues vcpu ioctls outside its 
thread?  While I much prefer wait_event_interruptible(), I don't want to 
break existing userspace.

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


-
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] [PATCH 5/5] Stop dropping so many RX packets in tap (v3)

2008-05-11 Thread Avi Kivity 
Anthony Liguori wrote:
> Normally, tap always reads packets and simply lets the client drop them if it
> cannot receive them.  For virtio-net, this results in massive packet loss and
> about an 80% performance loss in TCP throughput.
>
> This patch modifies qemu_send_packet() to only deliver a packet to a VLAN
> client if it doesn't have a fd_can_read method or the fd_can_read method
> indicates that it can receive packets.  We also return a status of whether
> any clients were able to receive the packet.
>
> If no clients were able to receive a packet, we buffer the packet until a
> client indicates that it can receive packets again.
>
> This patch also modifies the tap code to only read from the tap fd if at least
> one client on the VLAN is able to receive a packet.
>
> Finally, this patch changes the tap code to drain all possible packets from
> the tap device when the tap fd is readable.
>
>  
>  #if defined(CONFIG_SLIRP)
> @@ -3970,6 +3976,8 @@ typedef struct TAPState {
>  VLANClientState *vc;
>  int fd;
>  char down_script[1024];
> +char buf[4096];
> +int size;
>  } TAPState;
>   

This breaks large MTUs.

How about the other way round: when the vlan consumer detects it can no 
longer receive packets, it tells that to the vlan.  When all vlan 
consumers can no longer receive, tell the producer to stop producing.  
For the tap producer, this is simply removing its fd from the read poll 
list.  When a vlan consumer becomes ready to receive again, it tells the 
vlan, which tells the producers, which then install their fds back again.

This is  a bit difficult since virtio and tap are both consumers and 
producers, but could be made to work, I think.


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


-
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] Fwd: kernel module won't compile when using seperate build dir

2008-05-11 Thread Avi Kivity 
James Pike wrote:
> Sorry that doesn't work.
>
> This does.
>

> --- kvm/configure2008-05-02 19:20:13.0 +0800
> +++ kvm.new/configure2008-05-07 19:34:28.0 +0800
> @@ -2,6 +2,7 @@
>  
>  prefix=/usr/local
>  kerneldir=/lib/modules/$(uname -r)/build
> +kernelsrcdir=/lib/modules/$(uname -r)/source
>  cc=gcc
>  ld=ld
>  objcopy=objcopy

I don't think there is a guarantee that /source will be present, only 
/build.


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


-
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] [RFC] [VTD][patch 1/3] vt-d support for pci passthrough: kvm-vtd--kernel.patch

2008-05-11 Thread Avi Kivity 
Anthony Liguori wrote:
>> I don't think we can do page migration with VT-d.  You need to be able 
>> to detect whether the page has been changed by dma after you've copied 
>> it but before you changed the pte, but VT-d doesn't allow that AFAICT.
>> 
>
> Hrm, I would have to look at the VT-d but I suspect you're right.  
> That's unfortunate.
>
> That means mlock() isn't sufficient.  It also means that the VMAs can't 
> be updated while the guest is running.  Is there any way to lock a vma 
> region such that things like madvise/mmap(MAP_FIXED) will always fail?
>   

Userspace can simply not issue them.  Page migration is also controlled 
by userspace.

Once active memory defragmentation goes in, we need a way to tell the 
kernel that the allocation is unreclaimable, perhaps with a new mmap flag.

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


-
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] [PATCH 5/5] Stop dropping so many RX packets in tap (v3)

2008-05-11 Thread Anthony Liguori 
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Normally, tap always reads packets and simply lets the client drop 
>> them if it
>> cannot receive them.  For virtio-net, this results in massive packet 
>> loss and
>> about an 80% performance loss in TCP throughput.
>>
>> This patch modifies qemu_send_packet() to only deliver a packet to a 
>> VLAN
>> client if it doesn't have a fd_can_read method or the fd_can_read method
>> indicates that it can receive packets.  We also return a status of 
>> whether
>> any clients were able to receive the packet.
>>
>> If no clients were able to receive a packet, we buffer the packet 
>> until a
>> client indicates that it can receive packets again.
>>
>> This patch also modifies the tap code to only read from the tap fd if 
>> at least
>> one client on the VLAN is able to receive a packet.
>>
>> Finally, this patch changes the tap code to drain all possible 
>> packets from
>> the tap device when the tap fd is readable.
>>
>>  
>>  #if defined(CONFIG_SLIRP)
>> @@ -3970,6 +3976,8 @@ typedef struct TAPState {
>>  VLANClientState *vc;
>>  int fd;
>>  char down_script[1024];
>> +char buf[4096];
>> +int size;
>>  } TAPState;
>>   
>
> This breaks large MTUs.

They've always been broken for tap.

> How about the other way round: when the vlan consumer detects it can 
> no longer receive packets, it tells that to the vlan.  When all vlan 
> consumers can no longer receive, tell the producer to stop producing.  
> For the tap producer, this is simply removing its fd from the read 
> poll list.  When a vlan consumer becomes ready to receive again, it 
> tells the vlan, which tells the producers, which then install their 
> fds back again.

Yeah, that's a nice idea.   I'll think about it.  I don't know if it's 
really worth doing as an intermediate step though.  What I'd really like 
to do is have a vlan interface where consumers published all of their 
receive buffers.  Then there's no need for notifications of receive-ability.

Regards,

Anthony Liguori

> This is  a bit difficult since virtio and tap are both consumers and 
> producers, but could be made to work, I think.
>
>


-
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] [PATCH 5/5] Stop dropping so many RX packets in tap (v3)

2008-05-11 Thread Avi Kivity 
Anthony Liguori wrote:
>> How about the other way round: when the vlan consumer detects it can 
>> no longer receive packets, it tells that to the vlan.  When all vlan 
>> consumers can no longer receive, tell the producer to stop 
>> producing.  For the tap producer, this is simply removing its fd from 
>> the read poll list.  When a vlan consumer becomes ready to receive 
>> again, it tells the vlan, which tells the producers, which then 
>> install their fds back again.
>
> Yeah, that's a nice idea.   I'll think about it.  I don't know if it's 
> really worth doing as an intermediate step though.  What I'd really 
> like to do is have a vlan interface where consumers published all of 
> their receive buffers.  Then there's no need for notifications of 
> receive-ability.

That's definitely better, and is also more multiqueue nic / vringfd 
friendly.

I still think interrupt-on-halfway-mark is needed much more urgently.  
It deals with concurrency much better:

rx:
  host interrupts guest on halfway mark
  guest starts processing packets
  host keeps delivering

tx:
  guest kicks host on halfway mark
  host starts processing packets
  second vcpu on guest keeps on queueing

It's also much better with multiqueue NICs, where there's no socket 
buffer to hold the packets while we're out of descriptors.

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


-
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] [PATCH 5/5] Stop dropping so many RX packets in tap (v3)

2008-05-11 Thread Anthony Liguori 
Avi Kivity wrote:
> Anthony Liguori wrote:
>   
>>> How about the other way round: when the vlan consumer detects it can 
>>> no longer receive packets, it tells that to the vlan.  When all vlan 
>>> consumers can no longer receive, tell the producer to stop 
>>> producing.  For the tap producer, this is simply removing its fd from 
>>> the read poll list.  When a vlan consumer becomes ready to receive 
>>> again, it tells the vlan, which tells the producers, which then 
>>> install their fds back again.
>>>   
>> Yeah, that's a nice idea.   I'll think about it.  I don't know if it's 
>> really worth doing as an intermediate step though.  What I'd really 
>> like to do is have a vlan interface where consumers published all of 
>> their receive buffers.  Then there's no need for notifications of 
>> receive-ability.
>> 
>
> That's definitely better, and is also more multiqueue nic / vringfd 
> friendly.
>
> I still think interrupt-on-halfway-mark is needed much more urgently.  
> It deals with concurrency much better:
>   

We already sort of do this.  In try_fill_recv() in virtio-net.c, we try 
to allocate as many skbs as we can to fill the rx queue.  We keep track 
of how many we've been able to allocate.  Whenever we process an RX 
packet, we check to see if the current number of RX packets is less than 
half the maximum number of rx packets we've been able to allocate.

In the common case of small queues, this should have exactly the 
behavior you describe.  We don't currently suppress the RX notification 
even though we really could.  The can_receive changes are really the key 
to this.  Unless we are suppressing tap fd select()'ing, we can always 
suppress the RX notification.  That's been sitting on my TODO for a bit.

> rx:
>   host interrupts guest on halfway mark
>   guest starts processing packets
>   host keeps delivering
>
> tx:
>   guest kicks host on halfway mark
>   host starts processing packets
>   second vcpu on guest keeps on queueing
>   

I'm not convinced it's at all practical to suppress notifications in the 
front-end.  We simply don't know whether we'll get more packets which 
means we have to do TX mitigation within the front-end.  We've been 
there, it's not as nice as doing it in the back-end.

What we really ought to do in the back-end though, is start processing 
the TX packets as soon as we begin to do TX mitigation.  This would 
address the ping latency issue while also increasing throughput 
(hopefully).  One thing I've wanted to try is to register a bottom-half 
or a polling function so that the IO thread was always trying to process 
TX packets while the TX timer is active.

Regards,

Anthony Liguori

> It's also much better with multiqueue NICs, where there's no socket 
> buffer to hold the packets while we're out of descriptors.
>
>   


-
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] Windows PV driver for KVM

2008-05-11 Thread Dor Laor 

On Wed, 2008-05-07 at 21:17 +0800, Jiang, Yunhong wrote:
> Avi Kivity  wrote:
> > Jiang, Yunhong wrote:
> >> I noticed there is a windows PV driver based on virtIO in
> >> http://sourceforge.net/project/showfiles.php?group_id=180599
> >> 
> >> But when I enable the driver in guest, the guest will hang. I'm using
> >> changeset around April, 18. Since the driver is created in March, I
> >> assume the changeset in Apri should be ok.
> >> 
> >> Are there any special action needed to enable the PV driver in
> windows?
> >> Have anyone tried it recently?
> >> 
> > 
> > We are using it in production.  What HAL is the guest using?  Are you
> > running with smp? 
> 
> The HAL is ACPI multipprocessor PC. 
> It is a UP guest. But I do notice one thing strange. When I use device
> manager->Processors, I see a lot of CPU listed. But it is really a UP
> system and I can only get one cpu in the task manager->performance
> window. Not sure if that's the reason of the hang.
> 

We just fixed an smp bug for virtio (also triggered by single processor
with ACPI multiprocessor HAL). We'll publish a new binary tomorrow.

The reason you see multiple cpus although there is only one is that we
expose the maximum number in the bios. The system is actually uses the
required number so this behavior is ok.


> -- Yunhong Jiang
> 
> > 
> > --
> > Any sufficiently difficult bug is indistinguishable from a feature.
> 
> -
> 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


-
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] Windows PV driver for KVM

2008-05-11 Thread Jiang, Yunhong 
Dor Laor  wrote:
> On Wed, 2008-05-07 at 21:17 +0800, Jiang, Yunhong wrote:
>> Avi Kivity  wrote:

> We just fixed an smp bug for virtio (also triggered by single
processor
> with ACPI multiprocessor HAL). We'll publish a new binary tomorrow.
> 
> The reason you see multiple cpus although there is only one is that we
> expose the maximum number in the bios. The system is actually uses the
> required number so this behavior is ok.

Thanks for your clarification.  I will try the new one when it is
available.
I'm wondering when you publish the binary, is it possible to share the
pdb file also? That will be helpful if want to do some debug. 

> 
> 
>> -- Yunhong Jiang
>> 
>>> 
>>> --
>>> Any sufficiently difficult bug is indistinguishable from a feature.
>> 
>> 
> ---
> --
>> 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

-
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] [kvm-ia64-devel] [PATCH] KVM: Qemu: Build fix for kvm/ia64

2008-05-11 Thread Zhang, Xiantao 
 Could you help to try the attached one. 
Xiantao

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Avi Kivity
Sent: 2008年5月9日 23:56
To: Zhang, Xiantao
Cc: kvm-devel@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [kvm-ia64-devel] [PATCH] KVM: Qemu: Build fix for kvm/ia64

Zhang, Xiantao wrote:
> Avi, 
>   Please drop the previous one due to a wrong attachment. 
> Xiantao
>
> From a9f479197f0a0efa45a930309fad03fd690cba60 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Thu, 8 May 2008 10:16:05 +0800
> Subject: [PATCH] KVM: Qemu : IA-64 build fix.
>
> Remove unexisting header inclusion, and set correct phys_ram_size
> for ipf machine.
>   

Patch doesn't apply.  Can you recheck?


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


-
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-ia64-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel


0001-KVM-Qemu-IA-64-build-fix.patch
Description: 0001-KVM-Qemu-IA-64-build-fix.patch
-
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] [RFC][PATCH 3/4] KVM: VMX: Enable NMI with in-kernel irqchip

2008-05-11 Thread Yang, Sheng 
On Friday 09 May 2008 23:49:13 Avi Kivity wrote:
> Yang, Sheng wrote:
> > From 4942a5c35c97e5edb6fe1303e04fb86f25cac345 Mon Sep 17 00:00:00 2001
> > From: Sheng Yang <[EMAIL PROTECTED]>
> > Date: Thu, 8 May 2008 16:00:57 +0800
> > Subject: [PATCH 3/4] KVM: VMX: Enable NMI with in-kernel irqchip
> >
> >
> >  static void kvm_do_inject_irq(struct kvm_vcpu *vcpu)
> >  {
> > int word_index = __ffs(vcpu->arch.irq_summary);
> > @@ -2146,9 +2159,11 @@ static void do_interrupt_requests(struct kvm_vcpu
> > *vcpu,
> > /*
> >  * Interrupts blocked.  Wait for unblock.
> >  */
> > -   cpu_based_vm_exec_control |= CPU_BASED_VIRTUAL_INTR_PENDING;
> > +   cpu_based_vm_exec_control |=
> > +   CPU_BASED_VIRTUAL_INTR_PENDING;
> > else
> > -   cpu_based_vm_exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING;
> > +   cpu_based_vm_exec_control &=
> > +   ~CPU_BASED_VIRTUAL_INTR_PENDING;
>
> This seems spurious.

Sorry, seems I am too anxious to keep it in hand... I would like to check it 
much careful in the future.

>
> > /* We need to handle NMIs before interrupts are enabled */
> > -   if ((intr_info & INTR_INFO_INTR_TYPE_MASK) == 0x200) { /* nmi */
> > +   if ((intr_info & INTR_INFO_INTR_TYPE_MASK) == 0x200) {
> > KVMTRACE_0D(NMI, vcpu, handler);
> > -   asm("int $2");
> > +   if (!cpu_has_virtual_nmis())
> > +   asm("int $2");
> > }
> >  }
>
> That's a host nmi.  So does the PIN_BASED_VIRTUAL_NMI mean NMIs are
> handled like unacked host interrupts?

Not exactly. No host NMI here if Virtual_NMI is set. Copy from SDM 3B table 
20-5:

"If this control(Virtual NMIs) is 1, NMIs are never blocked and the “blocking 
by NMI” bit (bit 3) in the interruptibility-state field 
indicates “virtual-NMI blocking” (see Table 20-3). This control also 
interacts with the “NMI-window exiting” VM-execution control (see Section 
20.6.2)."

--
Thanks
Yang, Sheng

-
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

[kvm-devel] Чем грозит компаниям новый Гра достроительный кодекс?

2008-05-11 Thread Роснедвижимость 

Измeнeнuя в правoвoм рeгyлuрoванuu
граgoстрouтeльнoй geятeльнoстu в 2008 гogy

  Cанkт-Пeтeрбyрг
  19-21 мая 2008г.
  
  В прoграммe:

Граgoстрouтeльный kogekс РФ: гoсygарствeннoe рeгyлuрoванue развuтuя
  тeррuтoрuй u пoсeлeнuй, oпрegeлeнuя вugoв uспoльзoванuя зeмeльных
  yчастkoв, прoekтuрoванuя, стрouтeльства u рekoнстрykцuu oбъekтoв
  нegвuжuмoстu. Рeгyлuрoванue застрoйku тeррuтoрuй

Пoряgok прegoставлeнuя зeмeльных yчастkoв пog стрouтeльствo.
  Измeнeнue цeлeвoгo назначeнuя u разрeшeннoгo uспoльзoванuя зeмeльных
  yчастkoв. Oсoбeннoстu прuмeнeнuя нoвoгo Граgoстрouтeльнoгo kogekса РФ.
  Прuoбрeтeнue зeмeльных yчастkoв на тoргах.
  Правoвыe пoслegствuя самoвoльнoгo стрouтeльства

Зeмeльный kogekс u граgoстрouтeльная geятeльнoсть.
  Гoсygарствeнная рeгuстрацuя прав на зeмeльныe yчастku u распoлoжeнныe
  на нuх oбъekты нegвuжuмoстu. Рeгламeнт прegoставлeнuя зeмeльнoгo
  yчастkа в сoбствeннoсть. Oснoванuя oтkаза в прuoбрeтeнuu зeмeльнoгo
  yчастkа в сoбствeннoсть

Прoблeмныe вoпрoсы развuтuя застрoeнных тeррuтoрuй. Прoцegyра выgeлeнuя
  зeмeльных yчастkoв gля стрouтeльства. Прoблeмы распoряжeнuя зeмeльнымu
  yчастkамu uз нeразгранuчeннoй гoсygарствeннoй сoбствeннoстu на зeмлю
  в пoсeлeнuях

Kаgастрoвая oцeнkа зeмeль. Рынoчная, kаgастрoвая u нoрматuвная стouмoстu
  зeмeльных yчастkoв √ пoряgok u мeтoguku oпрegeлeнuя. Oпрegeлeнue цeны
  выkyпа зeмeльных yчастkoв пog прuватuзuрoваннымu зgанuямu u сooрyжeнuямu.
  Пoряgok oпрegeлeнuя стouмoстu выkyпа свoбogных зeмeльных yчастkoв

Пoряgok прoвegeнuя мeжeванuя u зeмлeyстрouтeльных рабoт.
  Мeтoguчeсkue рekoмeнgацuu прoвegeнuя зeмлeyстрoйства прu oбразoванuu
  нoвых u yпoряgoчeнuя сyщeствyющuх oбъekтoв зeмлeyстрoйства.
  Мeтoguчeсkue рekoмeнgацuu прoвegeнuя мeжeванuя oбъekтoв зeмлeyстрoйства

Oсoбeннoстu oфoрмлeнuя прав сoбствeннoстu прu фuнансuрoванuu пo goгoвoрy
  goлeвoгo стрouтeльства. Гoсygарствeнная пoлuтukа в oбластu  защuты прав
  yчастнukoв goлeвoгo стрouтeльства

Hoвыe трeбoванuя пoряgkа выgачu разрeшeнuя на стрouтeльствo,
  ввogа oбъekта в эkсплyатацuю

Oтвeтствeннoсть за нарyшeнue заkoнogатeльства o граgoстрouтeльнoй
  geятeльнoстu

  C пoлнoй прoграммoй сeмuнара Вы мoжeтe oзнаkoмuться,
  запрoсuв пo тeлeфoнy (812) 983-5ЧЗ9





-
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