[PATCH] KVM: Use kmalloc() instead of vmalloc() for KVM_[GS]ET_MSR
We don't need more than a page, and vmalloc() is slower (much slower recently due to a regression). Signed-off-by: Avi Kivity --- arch/x86/kvm/x86.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 84bfb51..76fbc32 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1626,7 +1626,7 @@ static int msr_io(struct kvm_vcpu *vcpu, struct kvm_msrs __user *user_msrs, r = -ENOMEM; size = sizeof(struct kvm_msr_entry) * msrs.nmsrs; - entries = vmalloc(size); + entries = kmalloc(size, GFP_KERNEL); if (!entries) goto out; @@ -1645,7 +1645,7 @@ static int msr_io(struct kvm_vcpu *vcpu, struct kvm_msrs __user *user_msrs, r = n; out_free: - vfree(entries); + kfree(entries); out: return r; } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: MMU: fix hugepage mapping corrupt caused by regression
This is the regression, the bug which is fixed by commit e09e90a5
is active now
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/paging_tmpl.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index a09e04c..d9a2742 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -374,13 +374,13 @@ static u64 *FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t
addr,
shadow_walk_next(&it)) {
gfn_t direct_gfn;
+ validate_direct_spte(vcpu, it.sptep, direct_access);
+
drop_large_spte(vcpu, it.sptep);
if (is_shadow_present_pte(*it.sptep))
continue;
- validate_direct_spte(vcpu, it.sptep, direct_access);
-
direct_gfn = gw->gfn & ~(KVM_PAGES_PER_HPAGE(it.level) - 1);
sp = kvm_mmu_get_page(vcpu, direct_gfn, addr, it.level-1,
--
1.6.1.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] KVM test: add test case to trigger the bug which cause hugepage mapping corrupt
The test case can trigger the bug that fixed by commit e09e90a5 in the kvm tree
to avoid regression
Signed-off-by: Xiao Guangrong
---
kvm/test/x86/access.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/kvm/test/x86/access.c b/kvm/test/x86/access.c
index be51a55..a833df5 100644
--- a/kvm/test/x86/access.c
+++ b/kvm/test/x86/access.c
@@ -629,6 +629,49 @@ static void ac_test_show(ac_test_t *at)
printf("%s", line);
}
+/*
+ * This test case is used to triger the bug which is fixed by
+ * commit e09e90a5 in the kvm tree
+ */
+static int corrupt_hugepage_triger(ac_pool_t *pool)
+{
+ac_test_t at1, at2;
+
+ac_test_init(&at1, (void *)(0x1234));
+ac_test_init(&at2, (void *)(0x));
+
+at2.flags[AC_CPU_CR0_WP] = 1;
+at2.flags[AC_PDE_PSE] = 1;
+at2.flags[AC_PDE_PRESENT] = 1;
+ac_test_setup_pte(&at2, pool);
+if (!ac_test_do_access(&at2))
+goto err;
+
+at1.flags[AC_CPU_CR0_WP] = 1;
+at1.flags[AC_PDE_PSE] = 1;
+at1.flags[AC_PDE_WRITABLE] = 1;
+at1.flags[AC_PDE_PRESENT] = 1;
+ac_test_setup_pte(&at1, pool);
+if (!ac_test_do_access(&at1))
+goto err;
+
+at1.flags[AC_ACCESS_WRITE] = 1;
+ac_set_expected_status(&at1);
+if (!ac_test_do_access(&at1))
+goto err;
+
+at2.flags[AC_ACCESS_WRITE] = 1;
+ac_set_expected_status(&at2);
+if (!ac_test_do_access(&at2))
+goto err;
+
+return 1;
+
+err:
+printf("corrupt_hugepage_triger test fail\n");
+return 0;
+}
+
int ac_test_exec(ac_test_t *at, ac_pool_t *pool)
{
int r;
@@ -656,6 +699,9 @@ int ac_test_run(void)
successes += ac_test_exec(&at, &pool);
} while (ac_test_bump(&at));
+++tests;
+successes += corrupt_hugepage_triger(&pool);
+
printf("\n%d tests, %d failures\n", tests, tests - successes);
return successes == tests;
--
1.6.1.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] KVM test: separate pool from ac_test_t struct
Separate pool from the ac_test_t struct, later we will use multiple ac_test_t
units, those units should allocate pte from the same pool to avoid mapping to
the same pte
Signed-off-by: Xiao Guangrong
---
kvm/test/x86/access.c | 71
1 files changed, 41 insertions(+), 30 deletions(-)
diff --git a/kvm/test/x86/access.c b/kvm/test/x86/access.c
index ebadae9..be51a55 100644
--- a/kvm/test/x86/access.c
+++ b/kvm/test/x86/access.c
@@ -127,12 +127,15 @@ typedef struct {
} idt_entry_t;
typedef struct {
-unsigned flags[NR_AC_FLAGS];
-void *virt;
-pt_element_t phys;
pt_element_t pt_pool;
unsigned pt_pool_size;
unsigned pt_pool_current;
+} ac_pool_t;
+
+typedef struct {
+unsigned flags[NR_AC_FLAGS];
+void *virt;
+pt_element_t phys;
pt_element_t *ptep;
pt_element_t expected_pte;
pt_element_t *pdep;
@@ -225,23 +228,29 @@ void set_efer_nx(int nx)
wrmsr(MSR_EFER, efer);
}
+static void ac_env_int(ac_pool_t *pool)
+{
+static idt_entry_t idt[256];
+
+memset(idt, 0, sizeof(idt));
+lidt(idt, 256);
+extern char page_fault, kernel_entry;
+set_idt_entry(&idt[14], &page_fault, 0);
+set_idt_entry(&idt[0x20], &kernel_entry, 3);
-void ac_test_init(ac_test_t *at)
+pool->pt_pool = 33 * 1024 * 1024;
+pool->pt_pool_size = 120 * 1024 * 1024 - pool->pt_pool;
+pool->pt_pool_current = 0;
+}
+
+void ac_test_init(ac_test_t *at, void *virt)
{
wrmsr(MSR_EFER, rdmsr(MSR_EFER) | EFER_NX_MASK);
set_cr0_wp(1);
for (int i = 0; i < NR_AC_FLAGS; ++i)
at->flags[i] = 0;
-at->virt = (void *)(0x1234 + 16 * smp_id());
+at->virt = virt;
at->phys = 32 * 1024 * 1024;
-at->pt_pool = 33 * 1024 * 1024;
-at->pt_pool_size = 120 * 1024 * 1024 - at->pt_pool;
-at->pt_pool_current = 0;
-memset(at->idt, 0, sizeof at->idt);
-lidt(at->idt, 256);
-extern char page_fault, kernel_entry;
-set_idt_entry(&at->idt[14], &page_fault, 0);
-set_idt_entry(&at->idt[0x20], &kernel_entry, 3);
}
int ac_test_bump_one(ac_test_t *at)
@@ -285,21 +294,21 @@ void invlpg(void *addr)
asm volatile ("invlpg (%0)" : : "r"(addr));
}
-pt_element_t ac_test_alloc_pt(ac_test_t *at)
+pt_element_t ac_test_alloc_pt(ac_pool_t *pool)
{
-pt_element_t ret = at->pt_pool + at->pt_pool_current;
-at->pt_pool_current += PAGE_SIZE;
+pt_element_t ret = pool->pt_pool + pool->pt_pool_current;
+pool->pt_pool_current += PAGE_SIZE;
return ret;
}
-_Bool ac_test_enough_room(ac_test_t *at)
+_Bool ac_test_enough_room(ac_pool_t *pool)
{
-return at->pt_pool_current + 4 * PAGE_SIZE <= at->pt_pool_size;
+return pool->pt_pool_current + 4 * PAGE_SIZE <= pool->pt_pool_size;
}
-void ac_test_reset_pt_pool(ac_test_t *at)
+void ac_test_reset_pt_pool(ac_pool_t *pool)
{
-at->pt_pool_current = 0;
+pool->pt_pool_current = 0;
}
void ac_set_expected_status(ac_test_t *at)
@@ -407,12 +416,12 @@ fault:
at->expected_error &= ~PFERR_FETCH_MASK;
}
-void ac_test_setup_pte(ac_test_t *at)
+void ac_test_setup_pte(ac_test_t *at, ac_pool_t *pool)
{
unsigned long root = read_cr3();
-if (!ac_test_enough_room(at))
- ac_test_reset_pt_pool(at);
+if (!ac_test_enough_room(pool))
+ ac_test_reset_pt_pool(pool);
at->ptep = 0;
for (int i = 4; i >= 1 && (i >= 2 || !at->flags[AC_PDE_PSE]); --i) {
@@ -423,12 +432,12 @@ void ac_test_setup_pte(ac_test_t *at)
case 4:
case 3:
pte = vroot[index];
- pte = ac_test_alloc_pt(at) | PT_PRESENT_MASK;
+ pte = ac_test_alloc_pt(pool) | PT_PRESENT_MASK;
pte |= PT_WRITABLE_MASK | PT_USER_MASK;
break;
case 2:
if (!at->flags[AC_PDE_PSE])
- pte = ac_test_alloc_pt(at);
+ pte = ac_test_alloc_pt(pool);
else {
pte = at->phys & PT_PSE_BASE_ADDR_MASK;
pte |= PT_PSE_MASK;
@@ -620,29 +629,31 @@ static void ac_test_show(ac_test_t *at)
printf("%s", line);
}
-int ac_test_exec(ac_test_t *at)
+int ac_test_exec(ac_test_t *at, ac_pool_t *pool)
{
int r;
if (verbose) {
ac_test_show(at);
}
-ac_test_setup_pte(at);
+ac_test_setup_pte(at, pool);
r = ac_test_do_access(at);
return r;
}
int ac_test_run(void)
{
-static ac_test_t at;
+ac_test_t at;
+ac_pool_t pool;
int tests, successes;
printf("run\n");
tests = successes = 0;
-ac_test_init(&at);
+ac_env_int(&pool);
+ac_test_init(&at, (void *)(0x1234 + 16 * smp_id()));
do {
++tests;
- successes += ac_test_exec(&at);
+ successes += ac_test_exec(&at, &pool);
} while (ac_test_bump(&at));
printf("\n%d tests, %d failures\n", tests, tests - successes);
--
1.6.1.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.ke
[PATCH 1/3] KVM test: separate expect status updates from ac_test_setup_pte() function
Separate expect status updates operation, later we can just modify the access
way(i,e the AC_ACCESS_* flags)
Signed-off-by: Xiao Guangrong
---
kvm/test/x86/access.c | 131 ++---
1 files changed, 69 insertions(+), 62 deletions(-)
diff --git a/kvm/test/x86/access.c b/kvm/test/x86/access.c
index 3338fbc..c7d7e29 100644
--- a/kvm/test/x86/access.c
+++ b/kvm/test/x86/access.c
@@ -302,72 +302,12 @@ void ac_test_reset_pt_pool(ac_test_t *at)
at->pt_pool_current = 0;
}
-void ac_test_setup_pte(ac_test_t *at)
+void ac_set_expected_status(ac_test_t *at)
{
-unsigned long root = read_cr3();
int pde_valid, pte_valid;
-if (!ac_test_enough_room(at))
- ac_test_reset_pt_pool(at);
-
-at->ptep = 0;
-for (int i = 4; i >= 1 && (i >= 2 || !at->flags[AC_PDE_PSE]); --i) {
- pt_element_t *vroot = va(root & PT_BASE_ADDR_MASK);
- unsigned index = ((unsigned long)at->virt >> (12 + (i-1) * 9)) & 511;
- pt_element_t pte = 0;
- switch (i) {
- case 4:
- case 3:
- pte = vroot[index];
- pte = ac_test_alloc_pt(at) | PT_PRESENT_MASK;
- pte |= PT_WRITABLE_MASK | PT_USER_MASK;
- break;
- case 2:
- if (!at->flags[AC_PDE_PSE])
- pte = ac_test_alloc_pt(at);
- else {
- pte = at->phys & PT_PSE_BASE_ADDR_MASK;
- pte |= PT_PSE_MASK;
- }
- if (at->flags[AC_PDE_PRESENT])
- pte |= PT_PRESENT_MASK;
- if (at->flags[AC_PDE_WRITABLE])
- pte |= PT_WRITABLE_MASK;
- if (at->flags[AC_PDE_USER])
- pte |= PT_USER_MASK;
- if (at->flags[AC_PDE_ACCESSED])
- pte |= PT_ACCESSED_MASK;
- if (at->flags[AC_PDE_DIRTY])
- pte |= PT_DIRTY_MASK;
- if (at->flags[AC_PDE_NX])
- pte |= PT_NX_MASK;
- if (at->flags[AC_PDE_BIT51])
- pte |= 1ull << 51;
- at->pdep = &vroot[index];
- break;
- case 1:
- pte = at->phys & PT_BASE_ADDR_MASK;
- if (at->flags[AC_PTE_PRESENT])
- pte |= PT_PRESENT_MASK;
- if (at->flags[AC_PTE_WRITABLE])
- pte |= PT_WRITABLE_MASK;
- if (at->flags[AC_PTE_USER])
- pte |= PT_USER_MASK;
- if (at->flags[AC_PTE_ACCESSED])
- pte |= PT_ACCESSED_MASK;
- if (at->flags[AC_PTE_DIRTY])
- pte |= PT_DIRTY_MASK;
- if (at->flags[AC_PTE_NX])
- pte |= PT_NX_MASK;
- if (at->flags[AC_PTE_BIT51])
- pte |= 1ull << 51;
- at->ptep = &vroot[index];
- break;
- }
- vroot[index] = pte;
- root = vroot[index];
-}
invlpg(at->virt);
+
if (at->ptep)
at->expected_pte = *at->ptep;
at->expected_pde = *at->pdep;
@@ -467,6 +407,73 @@ fault:
at->expected_error &= ~PFERR_FETCH_MASK;
}
+void ac_test_setup_pte(ac_test_t *at)
+{
+unsigned long root = read_cr3();
+
+if (!ac_test_enough_room(at))
+ ac_test_reset_pt_pool(at);
+
+at->ptep = 0;
+for (int i = 4; i >= 1 && (i >= 2 || !at->flags[AC_PDE_PSE]); --i) {
+ pt_element_t *vroot = va(root & PT_BASE_ADDR_MASK);
+ unsigned index = ((unsigned long)at->virt >> (12 + (i-1) * 9)) & 511;
+ pt_element_t pte = 0;
+ switch (i) {
+ case 4:
+ case 3:
+ pte = vroot[index];
+ pte = ac_test_alloc_pt(at) | PT_PRESENT_MASK;
+ pte |= PT_WRITABLE_MASK | PT_USER_MASK;
+ break;
+ case 2:
+ if (!at->flags[AC_PDE_PSE])
+ pte = ac_test_alloc_pt(at);
+ else {
+ pte = at->phys & PT_PSE_BASE_ADDR_MASK;
+ pte |= PT_PSE_MASK;
+ }
+ if (at->flags[AC_PDE_PRESENT])
+ pte |= PT_PRESENT_MASK;
+ if (at->flags[AC_PDE_WRITABLE])
+ pte |= PT_WRITABLE_MASK;
+ if (at->flags[AC_PDE_USER])
+ pte |= PT_USER_MASK;
+ if (at->flags[AC_PDE_ACCESSED])
+ pte |= PT_ACCESSED_MASK;
+ if (at->flags[AC_PDE_DIRTY])
+ pte |= PT_DIRTY_MASK;
+ if (at->flags[AC_PDE_NX])
+ pte |= PT_NX_MASK;
+ if (at->flags[AC_PDE_BIT51])
+ pte |= 1ull << 51;
+ at->pdep = &vroot[index];
+ break;
+ case 1:
+ pte = at->phys & PT_BASE_ADDR_MASK;
+ if (at->flags[AC_PTE_PRESENT])
+ pte |= PT_PRESENT_MASK;
+ if (at->flags[AC_PTE_WRITABLE])
+ pte |= PT_WRITABLE_MASK;
+ if (at->flags[AC_PTE_USER])
+ pte |= PT_USER_MASK;
+ if (at->flags[AC_PTE_ACCESSED])
+ pte |= PT_ACCESSED_MASK;
+ if (at->flags[AC_PTE_DIRTY])
+ pte |= PT_DIRTY_MASK;
+ if (at->flags[AC_PTE_NX])
about memory
i am new in virtualization and kvm. i get some questions ,hope u will help me . when qemu allocates memory for a vm , function get_free_slot is called to get free slot for a vm from global variable slots. so i understand that all vms share slots , on the other words, each vm get a slot_info in slot_info array. but in kernel , there is a statement: struct kvm_memory_slot *s = &kvm->memslots[i] parameter i represents the slot value from get_free_slot. so what puzzlee me is that slots in qemu is global variable and in kernel each kvm struct has a slots array and only use the memslots determined by the slot value from qemu. so what is the relationship? or what does kvm_memory_slot really stands for? thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Virtio network performance poorer than emulated e1000
On Thu, Jul 22, 2010 at 8:18 PM, Sridhar Samudrala wrote: > On Thu, 2010-07-22 at 19:53 -0400, Balachandar wrote: >> I am resending this email as Freddie didn't use 'reply to all' when >> replying to this message. I am also updating to answer Freddie's >> questions.. >> >> I can see that virtio network performance is poorer than emaulated >> e1000 nic. I did some simple ping test and with emulated e1000 the >> average rtt is around 600 microsec. With virtio the average rtt is 800 >> microsec. I am using a tap + bridge configuration. I run kvm as >> follows >> >> kvm -m 512 -hda vdisk.img \ >> -net nic,model=virtio \ >> -net tap,ifname=tap0,script=qemu-ifup,downscript=no > > With newer qemu-kvm, you need to use -netdev tap to enable checksum/gso > offloads. > > Try > -net nic,model=virtio,netdev=tap0 > -netdev tap,ifname=tap0,id=tap0,vhost=on,script=qemu-ifup,downscript=no > > Thanks > Sridhar >> I tried this one also but not much improvement. Actually i get a some improvement if i disabled the tx timeout timer in the virtio_net.h in qemu-kvm. I read that with vhost the data flow path differs from normal operation. So is the timeout applicable when we use vhost also? Actually i dont see any improvement with vhost. I am just wondering what am i missing? The thing that worries me is that emulated nic offers much greater performance than virtio with vhost. So i feel i am doing something wrong but unable to find it. >> I am running Debian squeeze distribution with guest and host kernel 2.6.34. >> >> Does anyone else see some results like this or is it only me? Could >> changing the distribution help as i am running a testing one? >> >> Actually we are having a custom application which just measures >> ping-pong latency. The results that i get with virtio is around 750 >> micro seconds. The result i get with emulated e1000 is around 250 >> micro sec. Also i tried to use vhost but the virtio latency remained >> the same. >> >> Also i tried the tests with guest and host 2.6.26 kernel. I get better >> results for virtio than e1000. I get 550 for e1000 and 500 for virtio. >> >> Actually my application needs as minimum latency as needed. I am ready >> to trade-off throughput and cpu utilization. I was very excited when i >> saw the vhost-net module with people claiming low latencies. I am >> worried that i am missing some performance offered by virtio and >> vhost. >> >> >> Thanks, >> Bala >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Virtio network performance poorer than emulated e1000
On Thu, 2010-07-22 at 19:53 -0400, Balachandar wrote: > I am resending this email as Freddie didn't use 'reply to all' when > replying to this message. I am also updating to answer Freddie's > questions.. > > I can see that virtio network performance is poorer than emaulated > e1000 nic. I did some simple ping test and with emulated e1000 the > average rtt is around 600 microsec. With virtio the average rtt is 800 > microsec. I am using a tap + bridge configuration. I run kvm as > follows > > kvm -m 512 -hda vdisk.img \ > -net nic,model=virtio \ > -net tap,ifname=tap0,script=qemu-ifup,downscript=no With newer qemu-kvm, you need to use -netdev tap to enable checksum/gso offloads. Try -net nic,model=virtio,netdev=tap0 -netdev tap,ifname=tap0,id=tap0,vhost=on,script=qemu-ifup,downscript=no Thanks Sridhar > > I am running Debian squeeze distribution with guest and host kernel 2.6.34. > > Does anyone else see some results like this or is it only me? Could > changing the distribution help as i am running a testing one? > > Actually we are having a custom application which just measures > ping-pong latency. The results that i get with virtio is around 750 > micro seconds. The result i get with emulated e1000 is around 250 > micro sec. Also i tried to use vhost but the virtio latency remained > the same. > > Also i tried the tests with guest and host 2.6.26 kernel. I get better > results for virtio than e1000. I get 550 for e1000 and 500 for virtio. > > Actually my application needs as minimum latency as needed. I am ready > to trade-off throughput and cpu utilization. I was very excited when i > saw the vhost-net module with people claiming low latencies. I am > worried that i am missing some performance offered by virtio and > vhost. > > > Thanks, > Bala > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Virtio network performance poorer than emulated e1000
I am resending this email as Freddie didn't use 'reply to all' when replying to this message. I am also updating to answer Freddie's questions.. I can see that virtio network performance is poorer than emaulated e1000 nic. I did some simple ping test and with emulated e1000 the average rtt is around 600 microsec. With virtio the average rtt is 800 microsec. I am using a tap + bridge configuration. I run kvm as follows kvm -m 512 -hda vdisk.img \ -net nic,model=virtio \ -net tap,ifname=tap0,script=qemu-ifup,downscript=no I am running Debian squeeze distribution with guest and host kernel 2.6.34. Does anyone else see some results like this or is it only me? Could changing the distribution help as i am running a testing one? Actually we are having a custom application which just measures ping-pong latency. The results that i get with virtio is around 750 micro seconds. The result i get with emulated e1000 is around 250 micro sec. Also i tried to use vhost but the virtio latency remained the same. Also i tried the tests with guest and host 2.6.26 kernel. I get better results for virtio than e1000. I get 550 for e1000 and 500 for virtio. Actually my application needs as minimum latency as needed. I am ready to trade-off throughput and cpu utilization. I was very excited when i saw the vhost-net module with people claiming low latencies. I am worried that i am missing some performance offered by virtio and vhost. Thanks, Bala -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Virtio network performance poorer than emulated e1000
On Thu, Jul 22, 2010 at 1:13 PM, Balachandar wrote: > I can see that virtio network performance is poorer than emaulated > e1000 nic. I did some simple ping test and with emulated e1000 the > average rtt is around 600 microsec. With virtio the average rtt is 800 > microsec. I am using a tap + bridge configuration. I run kvm as > follows > > kvm -m 512 -hda vdisk.img \ > -net nic,model=virtio \ > -net tap,ifname=tap0,script=qemu-ifup,downscript=no > > I am running Debian squeeze distribution with guest and host kernel 2.6.34. > > Does anyone else see some results like this or is it only me? Could > changing the distribution help as i am running a testing one? Have you done any testing beyond "ping"? Doing network throughput tests using ping is equivalent to using dd to benchmark disk drives: aka pointless. Do network file transfers. Use a network benchmarking tool. Do something more in-depth than "ping". -- Freddie Cash fjwc...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
Hello,
On 07/22/2010 05:58 PM, Michael S. Tsirkin wrote:
> All the tricky barrier pairing made me uncomfortable. So I came up with
> this on top (untested): if we do all operations under the spinlock, we
> can get by without barriers and atomics. And since we need the lock for
> list operations anyway, this should have no paerformance impact.
>
> What do you think?
I've created kthread_worker in wq#for-next tree and already converted
ivtv to use it. Once this lands in mainline, I think converting vhost
to use it would be better choice. kthread worker code uses basically
the same logic used in the vhost_workqueue code but is better
organized and documented. So, I think it would be better to stick
with the original implementation, as otherwise we're likely to just
decrease test coverage without much gain.
http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439
> @@ -151,37 +161,37 @@ static void vhost_vq_reset(struct vhost_dev *dev,
> static int vhost_worker(void *data)
> {
> struct vhost_dev *dev = data;
> - struct vhost_work *work;
> + struct vhost_work *work = NULL;
>
> -repeat:
> - set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/ kthread_stop */
> + for (;;) {
> + set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/
> kthread_stop */
>
> - if (kthread_should_stop()) {
> - __set_current_state(TASK_RUNNING);
> - return 0;
> - }
> + if (kthread_should_stop()) {
> + __set_current_state(TASK_RUNNING);
> + return 0;
> + }
>
> - work = NULL;
> - spin_lock_irq(&dev->work_lock);
> - if (!list_empty(&dev->work_list)) {
> - work = list_first_entry(&dev->work_list,
> - struct vhost_work, node);
> - list_del_init(&work->node);
> - }
> - spin_unlock_irq(&dev->work_lock);
> + spin_lock_irq(&dev->work_lock);
> + if (work) {
> + work->done_seq = work->queue_seq;
> + if (work->flushing)
> + wake_up_all(&work->done);
I don't think doing this before executing the function is correct, so
you'll have to release the lock, execute the function, regrab the lock
and then do the flush processing.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Virtio network performance poorer than emulated e1000
I can see that virtio network performance is poorer than emaulated e1000 nic. I did some simple ping test and with emulated e1000 the average rtt is around 600 microsec. With virtio the average rtt is 800 microsec. I am using a tap + bridge configuration. I run kvm as follows kvm -m 512 -hda vdisk.img \ -net nic,model=virtio \ -net tap,ifname=tap0,script=qemu-ifup,downscript=no I am running Debian squeeze distribution with guest and host kernel 2.6.34. Does anyone else see some results like this or is it only me? Could changing the distribution help as i am running a testing one? Thanks, Bala -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2275173 ] savevm is extremely slow
Bugs item #2275173, was opened at 2008-11-13 09:36 Message generated for change (Comment added) made by jessorensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2275173&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: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: savevm is extremely slow Initial Comment: In kvm-79, a 1.3MB snapshot has taken several minutes to savevm. In kvm-78 it was slightly faster taking only about one minute to savevm 2.4MB. It doesn't sound right to me. Also, Michael Tokarev is reporting the same thing on the kvm mailing list. kvm-79 Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz Ubuntu 8.04 Desktop amd64(x86_64) -- >Comment By: Jes Sorensen (jessorensen) Date: 2010-07-22 18:23 Message: Are you still seeing this problem with uptodate KVM or can we close the bug? Thanks, Jes -- Comment By: Avi Kivity (avik) Date: 2008-11-23 19:44 Message: A temporary workaround is to use -drive file=...,cache=writeback -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2275173&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
On Wed, Jun 02, 2010 at 08:40:00PM +0200, Tejun Heo wrote:
> Replace vhost_workqueue with per-vhost kthread. Other than callback
> argument change from struct work_struct * to struct vhost_work *,
> there's no visible change to vhost_poll_*() interface.
>
> This conversion is to make each vhost use a dedicated kthread so that
> resource control via cgroup can be applied.
>
> Partially based on Sridhar Samudrala's patch.
>
> * Updated to use sub structure vhost_work instead of directly using
> vhost_poll at Michael's suggestion.
>
> * Added flusher wake_up() optimization at Michael's suggestion.
>
> Signed-off-by: Tejun Heo
> Cc: Michael S. Tsirkin
> Cc: Sridhar Samudrala
All the tricky barrier pairing made me uncomfortable. So I came up with
this on top (untested): if we do all operations under the spinlock, we
can get by without barriers and atomics. And since we need the lock for
list operations anyway, this should have no paerformance impact.
What do you think?
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 0c6b533..7730a30 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -73,7 +73,7 @@ void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t
fn,
INIT_LIST_HEAD(&work->node);
work->fn = fn;
init_waitqueue_head(&work->done);
- atomic_set(&work->flushing, 0);
+ work->flushing = 0;
work->queue_seq = work->done_seq = 0;
}
@@ -99,13 +99,23 @@ void vhost_poll_stop(struct vhost_poll *poll)
void vhost_poll_flush(struct vhost_poll *poll)
{
struct vhost_work *work = &poll->work;
- int seq = work->queue_seq;
+ unsigned seq, left;
+ int flushing;
- atomic_inc(&work->flushing);
- smp_mb__after_atomic_inc(); /* mb flush-b0 paired with worker-b1 */
- wait_event(work->done, seq - work->done_seq <= 0);
- atomic_dec(&work->flushing);
- smp_mb__after_atomic_dec(); /* rmb flush-b1 paired with worker-b0 */
+ spin_lock_irq(&dev->work_lock);
+ seq = work->queue_seq;
+ work->flushing++;
+ spin_unlock_irq(&dev->work_lock);
+ wait_event(work->done, {
+ spin_lock_irq(&dev->work_lock);
+ left = work->done_seq - seq;
+ spin_unlock_irq(&dev->work_lock);
+ left < UINT_MAX / 2;
+ });
+ spin_lock_irq(&dev->work_lock);
+ flushing = --work->flushing;
+ spin_unlock_irq(&dev->work_lock);
+ BUG_ON(flushing < 0);
}
void vhost_poll_queue(struct vhost_poll *poll)
@@ -151,37 +161,37 @@ static void vhost_vq_reset(struct vhost_dev *dev,
static int vhost_worker(void *data)
{
struct vhost_dev *dev = data;
- struct vhost_work *work;
+ struct vhost_work *work = NULL;
-repeat:
- set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/ kthread_stop */
+ for (;;) {
+ set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/
kthread_stop */
- if (kthread_should_stop()) {
- __set_current_state(TASK_RUNNING);
- return 0;
- }
+ if (kthread_should_stop()) {
+ __set_current_state(TASK_RUNNING);
+ return 0;
+ }
- work = NULL;
- spin_lock_irq(&dev->work_lock);
- if (!list_empty(&dev->work_list)) {
- work = list_first_entry(&dev->work_list,
- struct vhost_work, node);
- list_del_init(&work->node);
- }
- spin_unlock_irq(&dev->work_lock);
+ spin_lock_irq(&dev->work_lock);
+ if (work) {
+ work->done_seq = work->queue_seq;
+ if (work->flushing)
+ wake_up_all(&work->done);
+ }
+ if (!list_empty(&dev->work_list)) {
+ work = list_first_entry(&dev->work_list,
+ struct vhost_work, node);
+ list_del_init(&work->node);
+ } else
+ work = NULL;
+ spin_unlock_irq(&dev->work_lock);
+
+ if (work) {
+ __set_current_state(TASK_RUNNING);
+ work->fn(work);
+ } else
+ schedule();
- if (work) {
- __set_current_state(TASK_RUNNING);
- work->fn(work);
- smp_wmb(); /* wmb worker-b0 paired with flush-b1 */
- work->done_seq = work->queue_seq;
- smp_mb(); /* mb worker-b1 paired with flush-b0 */
- if (atomic_read(&work->flushing))
- wake_up_all(&work->done);
- } else
- schedule();
-
- goto repeat;
+ }
}
long vhost_dev_init(struct vhost_dev *dev,
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 0e63091..36933
Re: [Qemu-devel] Using Linux's CPUSET for KVM VCPUs
On Thu, Jul 22, 2010 at 04:03:13PM +0200, Andre Przywara wrote: > Hi all, > > while working on NUMA host pinning, I experimented with vCPU affinity > within QEMU, but left it alone as it would complicate the code and would > not achieve better experience than using taskset with the monitor > provided thread ids like it is done currently. During that I looked at > Linux' CPUSET implementation > (/src/linux-2.6/Documentation/cgroups/cpusets.txt). > In brief, this is a pseudo file system based, truly hierarchical > implementation of restricting a set of processes (or threads, it uses > PIDs) to a certain subset of the machine. > Sadly we cannot leverage this for true guest NUMA memory assignment, but > it would work nice for pinning (or not) guest vCPUs. IIUC the 'cpuset.mems' tunable let you control the NUMA node that memory allocation will come out of. It isn't as flexible as numactl policies, since you can't request interleaving, but if you're just look to control node locality I think it would do. > I had the following > structure in mind: > For each guest there is a new CPUSET (mkdir $CPUSET_MNT/`cat > /proc/$$/cpuset`/kvm_$guestname). One could then assign the guest global > resources to this CPUSET. > For each vCPU there is a separate CPUSET located under this guest global > one. This would allow for easy manipulation of the pinning of vCPUs, > even from the console without any mgt app (although this could be easily > implemented in libvirt). FYI, if you have any cgroup controllers mounted, libvirt will already automatically create a dedicated sub-group for every guest you run. The main reason we use cgroups is that it lets us apply controls to a group of PIDs at once (eg cpu.cpu_shares to all threads within QEMU, instead of nice(2) on each individual threads). When dealing at the individual vCPU level there are single PIDs again, libvirt hasn't needed further cgroup subdivision, just using traditional Linux APIs instead. > / > | > +--/ kvm_guest_01 > | | > | +-- VCPU0 > | | > | +-- VCPU1 > | > +--/ kvm_guest_02 > ... > > What do you think about it? It is worth implementing this? Having at least one cgroup per guest has certainly proved valuable for libvirt's needs. If not using a mgmt API exposing vcpus (and other internal QEMU threads) via named sub-cgroups could be quite convenient Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError
On Thu, 22 Jul 2010 15:03:27 +0100
"Daniel P. Berrange" wrote:
> On Thu, Jul 22, 2010 at 10:50:00AM -0300, Luiz Capitulino wrote:
> > On Thu, 22 Jul 2010 14:45:35 +0100
> > "Daniel P. Berrange" wrote:
> >
> > > On Thu, Jul 22, 2010 at 10:28:39AM -0300, Luiz Capitulino wrote:
> > > > On Wed, 21 Jul 2010 20:06:56 +0100
> > > > "Daniel P. Berrange" wrote:
> > > >
> > > > > On Wed, Jul 21, 2010 at 03:44:14PM -0300, Luiz Capitulino wrote:
> > > > > > Another related issue is that, this probably should an async
> > > > > > handler. But
> > > > > > as we don't have the proper infrastructure yet, I'm ok with having
> > > > > > this in
> > > > > > its current form.
> > > > > >
> > > > > > > +- "hold_time": duration in milliseconds to hold the keys down
> > > > > > > (json-int, optional, default=100)
> > > > >
> > > > > Having 'hold-time' which applies to the full list of keys is limiting
> > > > > the flexibility of apps. eg, it means you can only do
> > > > >
> > > > >down ctrl
> > > > >down alt
> > > > >down f1
> > > > >wait 100ms
> > > > >up ctrl
> > > > >up alt
> > > > >up f1
> > > > >
> > > > > Again I can see why the impl works this way currently, because it is
> > > > > clearly a nicer option for humans. For a machine protocol though it
> > > > > seems sub-optimal. What if app needed more flexibility over ordering
> > > > > of press+release events eg to release in a different order
> > > > >
> > > > >down ctrl
> > > > >down alt
> > > > >down f1
> > > > >wait 100ms
> > > > >up f1
> > > > >up ctrl
> > > > >up alt
> > > > >
> > > > > Should we just follow VNC and explicitly have a up/down flag in
> > > > > the protocol & let press & release events be sent separately.
> > > > >
> > > > > { "execute": "sendkey", "arguments": { "keycode": 0x31, "down":
> > > > > true } }
> > > > >
> > > > > We could allow multiple keycodes in one message
> > > > >
> > > > > { "execute": "sendkey", "arguments": { "keycodes": [ 0x31, 0x32 ],
> > > > > "down": true } }
> > > > >
> > > > > but its not really adding critical functionality that can't be got by
> > > > > sending a sequence of sendkey commands in a row.
> > > >
> > > > Hm, looks good to me, but then the hold time would be the time period
> > > > between the down/up commands. This won't be reliable in case the client
> > > > wants to exactly wait 100ms, as we can have network latency, for
> > > > example.
> > > >
> > > > Isn't this a problem? I believe VNC doesn't have this feature, right?
> > >
> > > Correct, VNC just sends each individual press / release event as a
> > > separate
> > > message, so you can have network delay effects there too.
> > >
> > > If we needed to support precise delays safe from network delay for some
> > > simulation needs, then you'd probably need a more complex structure
> > > where you can provide a whole sequence of operations. And why stop at
> > > keys, including mouse movement & buttons to.
> > >
> > >{ "execute": "sendinput", "arguments": {
> > >"sequence" : [
> > > { "event": "keypress", "keycode": 0x31 },
> > > { "event": "keypress", "keycode": 0x75 },
> > > { "event": "wait", "delay": 100 },
> > > { "event": "mousepress", "button": 1 },
> > > { "event": "mousemove", "xdelta": 1, "ydelta": 1 },
> > > { "event": "keyrelease", "keycode": 0x31 },
> > > { "event": "wait", "delay": 100 },
> > > { "event": "keyrelease", "keycode": 0x75 },
> > > { "event": "mousepos", "x": 102, "y": 102 },
> > >]
> > >} }
> > >
> > > This is getting kind of advanced now. Whether we need this vs the simpler
> > > sendkey, mouse_move, etc command comes down to whether we need ability to
> > > set precise delays between events. We could stick with the individual
> > > simple commands & add a advanced one alter
> >
> > Yeah, agreed and I think the current design (ie. hold_time) is simpler.
>
> When I said stick with simpler sendkey, I mean the style I outlined
> without any hold time at all
>
> > > > > { "execute": "sendkey", "arguments": { "keycode": 0x31, "down":
> > > > > true } }
>
> If its good enough for VNC & SPICE, it should be good enough for most
> monitor users, even more so since QMP communication is usually over a
> low latency UNIX domain socket. I think hold time is a flawed concept
> as currently provide since it prevents up/down interleaving by sending
> a sequence of QMP commands.
I don't want to suck the QMP interface because of that, but the problem
here is how to maintain the user monitor's current behavior.
The best option is to wait for the user monitor/QMP split. This way the
hold time could be a feature of the user monitor command only.
Or, we could add a new command. But this would just be a workaround..
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.o
Using Linux's CPUSET for KVM VCPUs
Hi all, while working on NUMA host pinning, I experimented with vCPU affinity within QEMU, but left it alone as it would complicate the code and would not achieve better experience than using taskset with the monitor provided thread ids like it is done currently. During that I looked at Linux' CPUSET implementation (/src/linux-2.6/Documentation/cgroups/cpusets.txt). In brief, this is a pseudo file system based, truly hierarchical implementation of restricting a set of processes (or threads, it uses PIDs) to a certain subset of the machine. Sadly we cannot leverage this for true guest NUMA memory assignment, but it would work nice for pinning (or not) guest vCPUs. I had the following structure in mind: For each guest there is a new CPUSET (mkdir $CPUSET_MNT/`cat /proc/$$/cpuset`/kvm_$guestname). One could then assign the guest global resources to this CPUSET. For each vCPU there is a separate CPUSET located under this guest global one. This would allow for easy manipulation of the pinning of vCPUs, even from the console without any mgt app (although this could be easily implemented in libvirt). / | +--/ kvm_guest_01 | | | +-- VCPU0 | | | +-- VCPU1 | +--/ kvm_guest_02 ... What do you think about it? It is worth implementing this? Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448-3567-12 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError
On Thu, Jul 22, 2010 at 10:50:00AM -0300, Luiz Capitulino wrote:
> On Thu, 22 Jul 2010 14:45:35 +0100
> "Daniel P. Berrange" wrote:
>
> > On Thu, Jul 22, 2010 at 10:28:39AM -0300, Luiz Capitulino wrote:
> > > On Wed, 21 Jul 2010 20:06:56 +0100
> > > "Daniel P. Berrange" wrote:
> > >
> > > > On Wed, Jul 21, 2010 at 03:44:14PM -0300, Luiz Capitulino wrote:
> > > > > Another related issue is that, this probably should an async handler.
> > > > > But
> > > > > as we don't have the proper infrastructure yet, I'm ok with having
> > > > > this in
> > > > > its current form.
> > > > >
> > > > > > +- "hold_time": duration in milliseconds to hold the keys down
> > > > > > (json-int, optional, default=100)
> > > >
> > > > Having 'hold-time' which applies to the full list of keys is limiting
> > > > the flexibility of apps. eg, it means you can only do
> > > >
> > > >down ctrl
> > > >down alt
> > > >down f1
> > > >wait 100ms
> > > >up ctrl
> > > >up alt
> > > >up f1
> > > >
> > > > Again I can see why the impl works this way currently, because it is
> > > > clearly a nicer option for humans. For a machine protocol though it
> > > > seems sub-optimal. What if app needed more flexibility over ordering
> > > > of press+release events eg to release in a different order
> > > >
> > > >down ctrl
> > > >down alt
> > > >down f1
> > > >wait 100ms
> > > >up f1
> > > >up ctrl
> > > >up alt
> > > >
> > > > Should we just follow VNC and explicitly have a up/down flag in
> > > > the protocol & let press & release events be sent separately.
> > > >
> > > > { "execute": "sendkey", "arguments": { "keycode": 0x31, "down": true
> > > > } }
> > > >
> > > > We could allow multiple keycodes in one message
> > > >
> > > > { "execute": "sendkey", "arguments": { "keycodes": [ 0x31, 0x32 ],
> > > > "down": true } }
> > > >
> > > > but its not really adding critical functionality that can't be got by
> > > > sending a sequence of sendkey commands in a row.
> > >
> > > Hm, looks good to me, but then the hold time would be the time period
> > > between the down/up commands. This won't be reliable in case the client
> > > wants to exactly wait 100ms, as we can have network latency, for example.
> > >
> > > Isn't this a problem? I believe VNC doesn't have this feature, right?
> >
> > Correct, VNC just sends each individual press / release event as a separate
> > message, so you can have network delay effects there too.
> >
> > If we needed to support precise delays safe from network delay for some
> > simulation needs, then you'd probably need a more complex structure
> > where you can provide a whole sequence of operations. And why stop at
> > keys, including mouse movement & buttons to.
> >
> >{ "execute": "sendinput", "arguments": {
> >"sequence" : [
> > { "event": "keypress", "keycode": 0x31 },
> > { "event": "keypress", "keycode": 0x75 },
> > { "event": "wait", "delay": 100 },
> > { "event": "mousepress", "button": 1 },
> > { "event": "mousemove", "xdelta": 1, "ydelta": 1 },
> > { "event": "keyrelease", "keycode": 0x31 },
> > { "event": "wait", "delay": 100 },
> > { "event": "keyrelease", "keycode": 0x75 },
> > { "event": "mousepos", "x": 102, "y": 102 },
> >]
> >} }
> >
> > This is getting kind of advanced now. Whether we need this vs the simpler
> > sendkey, mouse_move, etc command comes down to whether we need ability to
> > set precise delays between events. We could stick with the individual
> > simple commands & add a advanced one alter
>
> Yeah, agreed and I think the current design (ie. hold_time) is simpler.
When I said stick with simpler sendkey, I mean the style I outlined
without any hold time at all
> > > > { "execute": "sendkey", "arguments": { "keycode": 0x31, "down": true
> > > > } }
If its good enough for VNC & SPICE, it should be good enough for most
monitor users, even more so since QMP communication is usually over a
low latency UNIX domain socket. I think hold time is a flawed concept
as currently provide since it prevents up/down interleaving by sending
a sequence of QMP commands.
Daniel
--
|: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError
On Thu, 22 Jul 2010 14:45:35 +0100
"Daniel P. Berrange" wrote:
> On Thu, Jul 22, 2010 at 10:28:39AM -0300, Luiz Capitulino wrote:
> > On Wed, 21 Jul 2010 20:06:56 +0100
> > "Daniel P. Berrange" wrote:
> >
> > > On Wed, Jul 21, 2010 at 03:44:14PM -0300, Luiz Capitulino wrote:
> > > > Another related issue is that, this probably should an async handler.
> > > > But
> > > > as we don't have the proper infrastructure yet, I'm ok with having this
> > > > in
> > > > its current form.
> > > >
> > > > > +- "hold_time": duration in milliseconds to hold the keys down
> > > > > (json-int, optional, default=100)
> > >
> > > Having 'hold-time' which applies to the full list of keys is limiting
> > > the flexibility of apps. eg, it means you can only do
> > >
> > >down ctrl
> > >down alt
> > >down f1
> > >wait 100ms
> > >up ctrl
> > >up alt
> > >up f1
> > >
> > > Again I can see why the impl works this way currently, because it is
> > > clearly a nicer option for humans. For a machine protocol though it
> > > seems sub-optimal. What if app needed more flexibility over ordering
> > > of press+release events eg to release in a different order
> > >
> > >down ctrl
> > >down alt
> > >down f1
> > >wait 100ms
> > >up f1
> > >up ctrl
> > >up alt
> > >
> > > Should we just follow VNC and explicitly have a up/down flag in
> > > the protocol & let press & release events be sent separately.
> > >
> > > { "execute": "sendkey", "arguments": { "keycode": 0x31, "down": true }
> > > }
> > >
> > > We could allow multiple keycodes in one message
> > >
> > > { "execute": "sendkey", "arguments": { "keycodes": [ 0x31, 0x32 ],
> > > "down": true } }
> > >
> > > but its not really adding critical functionality that can't be got by
> > > sending a sequence of sendkey commands in a row.
> >
> > Hm, looks good to me, but then the hold time would be the time period
> > between the down/up commands. This won't be reliable in case the client
> > wants to exactly wait 100ms, as we can have network latency, for example.
> >
> > Isn't this a problem? I believe VNC doesn't have this feature, right?
>
> Correct, VNC just sends each individual press / release event as a separate
> message, so you can have network delay effects there too.
>
> If we needed to support precise delays safe from network delay for some
> simulation needs, then you'd probably need a more complex structure
> where you can provide a whole sequence of operations. And why stop at
> keys, including mouse movement & buttons to.
>
>{ "execute": "sendinput", "arguments": {
>"sequence" : [
> { "event": "keypress", "keycode": 0x31 },
> { "event": "keypress", "keycode": 0x75 },
> { "event": "wait", "delay": 100 },
> { "event": "mousepress", "button": 1 },
> { "event": "mousemove", "xdelta": 1, "ydelta": 1 },
> { "event": "keyrelease", "keycode": 0x31 },
> { "event": "wait", "delay": 100 },
> { "event": "keyrelease", "keycode": 0x75 },
> { "event": "mousepos", "x": 102, "y": 102 },
>]
>} }
>
> This is getting kind of advanced now. Whether we need this vs the simpler
> sendkey, mouse_move, etc command comes down to whether we need ability to
> set precise delays between events. We could stick with the individual
> simple commands & add a advanced one alter
Yeah, agreed and I think the current design (ie. hold_time) is simpler.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError
On Thu, Jul 22, 2010 at 10:28:39AM -0300, Luiz Capitulino wrote:
> On Wed, 21 Jul 2010 20:06:56 +0100
> "Daniel P. Berrange" wrote:
>
> > On Wed, Jul 21, 2010 at 03:44:14PM -0300, Luiz Capitulino wrote:
> > > Another related issue is that, this probably should an async handler. But
> > > as we don't have the proper infrastructure yet, I'm ok with having this in
> > > its current form.
> > >
> > > > +- "hold_time": duration in milliseconds to hold the keys down
> > > > (json-int, optional, default=100)
> >
> > Having 'hold-time' which applies to the full list of keys is limiting
> > the flexibility of apps. eg, it means you can only do
> >
> >down ctrl
> >down alt
> >down f1
> >wait 100ms
> >up ctrl
> >up alt
> >up f1
> >
> > Again I can see why the impl works this way currently, because it is
> > clearly a nicer option for humans. For a machine protocol though it
> > seems sub-optimal. What if app needed more flexibility over ordering
> > of press+release events eg to release in a different order
> >
> >down ctrl
> >down alt
> >down f1
> >wait 100ms
> >up f1
> >up ctrl
> >up alt
> >
> > Should we just follow VNC and explicitly have a up/down flag in
> > the protocol & let press & release events be sent separately.
> >
> > { "execute": "sendkey", "arguments": { "keycode": 0x31, "down": true } }
> >
> > We could allow multiple keycodes in one message
> >
> > { "execute": "sendkey", "arguments": { "keycodes": [ 0x31, 0x32 ],
> > "down": true } }
> >
> > but its not really adding critical functionality that can't be got by
> > sending a sequence of sendkey commands in a row.
>
> Hm, looks good to me, but then the hold time would be the time period
> between the down/up commands. This won't be reliable in case the client
> wants to exactly wait 100ms, as we can have network latency, for example.
>
> Isn't this a problem? I believe VNC doesn't have this feature, right?
Correct, VNC just sends each individual press / release event as a separate
message, so you can have network delay effects there too.
If we needed to support precise delays safe from network delay for some
simulation needs, then you'd probably need a more complex structure
where you can provide a whole sequence of operations. And why stop at
keys, including mouse movement & buttons to.
{ "execute": "sendinput", "arguments": {
"sequence" : [
{ "event": "keypress", "keycode": 0x31 },
{ "event": "keypress", "keycode": 0x75 },
{ "event": "wait", "delay": 100 },
{ "event": "mousepress", "button": 1 },
{ "event": "mousemove", "xdelta": 1, "ydelta": 1 },
{ "event": "keyrelease", "keycode": 0x31 },
{ "event": "wait", "delay": 100 },
{ "event": "keyrelease", "keycode": 0x75 },
{ "event": "mousepos", "x": 102, "y": 102 },
]
} }
This is getting kind of advanced now. Whether we need this vs the simpler
sendkey, mouse_move, etc command comes down to whether we need ability to
set precise delays between events. We could stick with the individual
simple commands & add a advanced one alter
Daniel
--
|: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError
On Wed, 21 Jul 2010 23:30:56 +0300
Michael Goldish wrote:
> On 07/21/2010 09:44 PM, Luiz Capitulino wrote:
> > On Sun, 18 Jul 2010 15:43:55 +0300
> > Michael Goldish wrote:
> >
> >> Signed-off-by: Michael Goldish
> >
> > Do you need this for 0.13? I think the development window is already closed.
>
> No, it's not urgent.
>
> >> ---
> >> monitor.c | 15 ---
> >> qemu-monitor.hx | 22 +-
> >> qerror.c| 12
> >> qerror.h|9 +
> >> 4 files changed, 50 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/monitor.c b/monitor.c
> >> index d5377de..082c29d 100644
> >> --- a/monitor.c
> >> +++ b/monitor.c
> >> @@ -1614,7 +1614,7 @@ static void release_keys(void *opaque)
> >> }
> >> }
> >>
> >> -static void do_sendkey(Monitor *mon, const QDict *qdict)
> >> +static int do_sendkey(Monitor *mon, const QDict *qdict, QObject
> >> **ret_data)
> >> {
> >> char keyname_buf[16];
> >> char *separator;
> >> @@ -1636,18 +1636,18 @@ static void do_sendkey(Monitor *mon, const QDict
> >> *qdict)
> >> if (keyname_len > 0) {
> >> pstrcpy(keyname_buf, sizeof(keyname_buf), string);
> >> if (keyname_len > sizeof(keyname_buf) - 1) {
> >> -monitor_printf(mon, "invalid key: '%s...'\n",
> >> keyname_buf);
> >> -return;
> >> +qerror_report(QERR_INVALID_KEY, keyname_buf);
> >> +return -1;
> >> }
> >> if (i == MAX_KEYCODES) {
> >> -monitor_printf(mon, "too many keys\n");
> >> -return;
> >> +qerror_report(QERR_TOO_MANY_KEYS);
> >> +return -1;
> >> }
> >> keyname_buf[keyname_len] = 0;
> >> keycode = get_keycode(keyname_buf);
> >> if (keycode < 0) {
> >> -monitor_printf(mon, "unknown key: '%s'\n", keyname_buf);
> >> -return;
> >> +qerror_report(QERR_UNKNOWN_KEY, keyname_buf);
> >> +return -1;
> >> }
> >> keycodes[i++] = keycode;
> >> }
> >> @@ -1666,6 +1666,7 @@ static void do_sendkey(Monitor *mon, const QDict
> >> *qdict)
> >> /* delayed key up events */
> >> qemu_mod_timer(key_timer, qemu_get_clock(vm_clock) +
> >> muldiv64(get_ticks_per_sec(), hold_time, 1000));
> >> +return 0;
> >> }
> >>
> >> static int mouse_button_state;
> >> diff --git a/qemu-monitor.hx b/qemu-monitor.hx
> >> index f7e46c4..8b6cf09 100644
> >> --- a/qemu-monitor.hx
> >> +++ b/qemu-monitor.hx
> >> @@ -532,7 +532,8 @@ ETEXI
> >> .args_type = "string:s,hold_time:i?",
> >> .params = "keys [hold_ms]",
> >> .help = "send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
> >> default hold time=100 ms)",
> >> -.mhandler.cmd = do_sendkey,
> >> +.user_print = monitor_user_noop,
> >> +.mhandler.cmd_new = do_sendkey,
> >> },
> >>
> >> STEXI
> >> @@ -549,6 +550,25 @@ sendkey ctrl-alt-f1
> >> This command is useful to send keys that your graphical user interface
> >> intercepts at low level, such as @code{ctrl-alt-f1} in X Window.
> >> ETEXI
> >> +SQMP
> >> +sendkey
> >> +---
> >> +
> >> +Send keys to the emulator.
> >> +
> >> +Arguments:
> >> +
> >> +- "string": key names or key codes in hexadecimal format separated by
> >> dashes (json-string)
> >
> > This is leaking bad stuff from the user monitor into QMP.
> >
> > I think we should have a "keys" key, which accepts an array of keys. Strings
> > are key names, integers are key codes. Unfortunately, key codes will have to
> > be specified in decimal.
> >
> > Example:
> >
> > { "execute": "sendkey", "arguments": { "keys": ["foo", 10, "bar", 15] } }
> >
> > However, in order to maintain the current user monitor behavior, you will
> > have to add a new args_type so that you can move the current parsing out
> > of the handler to the user monitor parser. Then you'll have to change the
> > handler to work with an array.
>
> What do you mean by "add a new args_type"? Do you mean I should add a
> new type 'a', similar to 's' and 'i', that represents a dash separated
> string/int array? If so, I suppose obtaining the array in do_sendkey()
> would involve something like
>
> QList *keys = qdict_get_qlist(qdict, "keys");
>
> Is this correct? I'm just asking to be sure.
It's exactly that. The user monitor does the fancy user parsing, handlers
handle QMP data only.
But note that the recommended QMP development process is to send the
documentation patch first, as an RFC. This way we can discuss and stabilize
the interface before touching the code (which is easier and avoids the
code dictating the interface).
So, it's a good idea to rewrite the documentation based on my discussion
with Daniel, and re-send it.
This process is not documented yet, will send a patch shortly.
> >
Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError
On Wed, 21 Jul 2010 20:06:56 +0100
"Daniel P. Berrange" wrote:
> On Wed, Jul 21, 2010 at 03:44:14PM -0300, Luiz Capitulino wrote:
> > On Sun, 18 Jul 2010 15:43:55 +0300
> > Michael Goldish wrote:
> >
> > > Signed-off-by: Michael Goldish
> >
> > Do you need this for 0.13? I think the development window is already closed.
> >
> > > ---
> > > monitor.c | 15 ---
> > > qemu-monitor.hx | 22 +-
> > > qerror.c| 12
> > > qerror.h|9 +
> > > 4 files changed, 50 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/monitor.c b/monitor.c
> > > index d5377de..082c29d 100644
> > > --- a/monitor.c
> > > +++ b/monitor.c
> > > @@ -1614,7 +1614,7 @@ static void release_keys(void *opaque)
> > > }
> > > }
> > >
> > > -static void do_sendkey(Monitor *mon, const QDict *qdict)
> > > +static int do_sendkey(Monitor *mon, const QDict *qdict, QObject
> > > **ret_data)
> > > {
> > > char keyname_buf[16];
> > > char *separator;
> > > @@ -1636,18 +1636,18 @@ static void do_sendkey(Monitor *mon, const QDict
> > > *qdict)
> > > if (keyname_len > 0) {
> > > pstrcpy(keyname_buf, sizeof(keyname_buf), string);
> > > if (keyname_len > sizeof(keyname_buf) - 1) {
> > > -monitor_printf(mon, "invalid key: '%s...'\n",
> > > keyname_buf);
> > > -return;
> > > +qerror_report(QERR_INVALID_KEY, keyname_buf);
> > > +return -1;
> > > }
> > > if (i == MAX_KEYCODES) {
> > > -monitor_printf(mon, "too many keys\n");
> > > -return;
> > > +qerror_report(QERR_TOO_MANY_KEYS);
> > > +return -1;
> > > }
> > > keyname_buf[keyname_len] = 0;
> > > keycode = get_keycode(keyname_buf);
> > > if (keycode < 0) {
> > > -monitor_printf(mon, "unknown key: '%s'\n", keyname_buf);
> > > -return;
> > > +qerror_report(QERR_UNKNOWN_KEY, keyname_buf);
> > > +return -1;
> > > }
> > > keycodes[i++] = keycode;
> > > }
> > > @@ -1666,6 +1666,7 @@ static void do_sendkey(Monitor *mon, const QDict
> > > *qdict)
> > > /* delayed key up events */
> > > qemu_mod_timer(key_timer, qemu_get_clock(vm_clock) +
> > > muldiv64(get_ticks_per_sec(), hold_time, 1000));
> > > +return 0;
> > > }
> > >
> > > static int mouse_button_state;
> > > diff --git a/qemu-monitor.hx b/qemu-monitor.hx
> > > index f7e46c4..8b6cf09 100644
> > > --- a/qemu-monitor.hx
> > > +++ b/qemu-monitor.hx
> > > @@ -532,7 +532,8 @@ ETEXI
> > > .args_type = "string:s,hold_time:i?",
> > > .params = "keys [hold_ms]",
> > > .help = "send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
> > > default hold time=100 ms)",
> > > -.mhandler.cmd = do_sendkey,
> > > +.user_print = monitor_user_noop,
> > > +.mhandler.cmd_new = do_sendkey,
> > > },
> > >
> > > STEXI
> > > @@ -549,6 +550,25 @@ sendkey ctrl-alt-f1
> > > This command is useful to send keys that your graphical user interface
> > > intercepts at low level, such as @code{ctrl-alt-f1} in X Window.
> > > ETEXI
> > > +SQMP
> > > +sendkey
> > > +---
> > > +
> > > +Send keys to the emulator.
> > > +
> > > +Arguments:
> > > +
> > > +- "string": key names or key codes in hexadecimal format separated by
> > > dashes (json-string)
> >
> > This is leaking bad stuff from the user monitor into QMP.
> >
> > I think we should have a "keys" key, which accepts an array of keys. Strings
> > are key names, integers are key codes. Unfortunately, key codes will have to
> > be specified in decimal.
>
> I can see why keynames are nice in the text monitor, but is there a need
> for JSON mode to accept keynames too ? If we're focusing on providing a
> machine protocol, then keycodes seem like they sufficient to me. Apps can
> using the command can provide symbol constants for the keycodes, or string
> if actually needed by their end users
Right. That should be a user monitor's feature, not QMP's.
> > Example:
> >
> > { "execute": "sendkey", "arguments": { "keys": ["foo", 10, "bar", 15] } }
> >
> > However, in order to maintain the current user monitor behavior, you will
> > have to add a new args_type so that you can move the current parsing out
> > of the handler to the user monitor parser. Then you'll have to change the
> > handler to work with an array.
> >
> > A bit of work.
> >
> > Another related issue is that, this probably should an async handler. But
> > as we don't have the proper infrastructure yet, I'm ok with having this in
> > its current form.
> >
> > > +- "hold_time": duration in milliseconds to hold the keys down (json-int,
> > > optional, default=100)
>
> Having 'hold-time' which applies to the full list of keys
Re: about using vmcall instruction
吴忠远 wrote:
> an module is executed in guest using vmcall instruction. then host
> handler the vmcall exit and read the registers value. but ax,cx,dx get
> the correct values while bx and si get the worong. what is the
> problem.
> code in guest is :
> __asm__ ("mov $10,%ax");
> __asm__ ("mov $20,%bx");
> __asm__ ("mov $30,%cx");
> __asm__ ("mov $40,%dx");
> __asm__ ("mov $50,%si");
> __asm__ ("vmcall");
> host output :
> HYPER CALL IS CALLED AND THE NR IS 10,bx is -526778348,cx is 30,dx is
> 40,si is -1017839566
> so ax(NR) ,cx,dx values are correct .but bx and si values are wrong.why?
Nothing, you just set the lower 16 bits of the registers and output at
least 32 bits on the host. The upper 16 bits are left from the previous
code in the guest. So EBX is 0xe09a0014 (with the lower 16 bits being
0x14=20) and ESI is c3550032 with the lower 16 bits being 0x32=50.
Please either use ebx and esi in the guest code or mask the registers to
16 bits in the host.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d regression issue
On Thu, Jul 22, 2010 at 08:32:31PM +0800, Hao, Xudong wrote:
> Well, this patch works fine for me.
>
Looks like userspace problem then. Userspace relied on something that
was not guarantied by the kernel (access to read only page forwarded to
userspace as MMOI).
> Gleb Natapov wrote:
> > On Thu, Jul 22, 2010 at 07:11:34PM +0800, Hao, Xudong wrote:
> >> Gleb,
> >> This patch does not work either, qemu stoped @ Starting Seabios.
> >>
> > And this one?
> >
> > diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> > index 2bba22f..b7e7dc0 100644
> > --- a/hw/device-assignment.c
> > +++ b/hw/device-assignment.c
> > @@ -238,9 +238,10 @@ static void
> > assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
> > DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
> > m = cpu_register_io_memory(slow_bar_read, NULL, region);
> > -else
> > +else {
> > m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> > region); -cpu_register_physical_memory(e_phys, e_size, m);
> > +cpu_register_physical_memory(e_phys, e_size, m);
> > +}
> >
> > /* MSI-X MMIO page */
> > if ((e_size > 0) &&
> > @@ -272,7 +273,8 @@ static void assigned_dev_iomem_map(PCIDevice
> > *pci_dev, int region_num, if (region_num == PCI_ROM_SLOT)
> > flags |= IO_MEM_ROM;
> >
> > -cpu_register_physical_memory(e_phys, e_size,
> > region->memory_index | flags); +if (region_num !=
> > PCI_ROM_SLOT) + cpu_register_physical_memory(e_phys, e_size,
> > region->memory_index | flags);
> >
> > /* deal with MSI-X MMIO page */
> > if (real_region->base_addr <= r_dev->msix_table_addr &&
>
>
>
> Thanks,
> Xudong
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.35-rc1 regression with pvclock and smp guests
Hi, I found a regression with pvclock and SMP KVM _guests_. PVCLOCK enabled guest kernels boot with qemu-kvm.git and with smp=1, but with smp=2 halt at: Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled (last line shown) I bisected this down to: commit 489fb490dbf8dab0249ad82b56688ae3842a79e8 Author: Glauber Costa Date: Tue May 11 12:17:40 2010 -0400 x86, paravirt: Add a global synchronization point for pvclock One commit before works, smp=1 always works, disabling PVCLOCK works. Using qemu-kvm-0.12.4 works, too. Having PVCLOCK enabled and with smp=2 the kernel halts without any further message. This is still the case with the lastest tip. Even pinning both VCPU threads to the same host core show the bug. The bug triggers on all hosts I tested, an single socket quadcore Athlon, a dual socket dualcore K8-Opteron and a quad socket 12core Opteron. Please note that this is the guest kernel, the host kernel does not matter. I have no idea (and don't feel like ;-) debugging this, so I hope someone will find and fix the bug. Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448-3567-12 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: VT-d regression issue
Well, this patch works fine for me.
Gleb Natapov wrote:
> On Thu, Jul 22, 2010 at 07:11:34PM +0800, Hao, Xudong wrote:
>> Gleb,
>> This patch does not work either, qemu stoped @ Starting Seabios.
>>
> And this one?
>
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 2bba22f..b7e7dc0 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -238,9 +238,10 @@ static void
> assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
> DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
> m = cpu_register_io_memory(slow_bar_read, NULL, region);
> -else
> +else {
> m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> region); -cpu_register_physical_memory(e_phys, e_size, m);
> +cpu_register_physical_memory(e_phys, e_size, m);
> +}
>
> /* MSI-X MMIO page */
> if ((e_size > 0) &&
> @@ -272,7 +273,8 @@ static void assigned_dev_iomem_map(PCIDevice
> *pci_dev, int region_num, if (region_num == PCI_ROM_SLOT)
> flags |= IO_MEM_ROM;
>
> -cpu_register_physical_memory(e_phys, e_size,
> region->memory_index | flags); +if (region_num !=
> PCI_ROM_SLOT) + cpu_register_physical_memory(e_phys, e_size,
> region->memory_index | flags);
>
> /* deal with MSI-X MMIO page */
> if (real_region->base_addr <= r_dev->msix_table_addr &&
Thanks,
Xudong--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-1834585 ] install from iso fails on 2.6.23.8 kernel
Bugs item #1834585, was opened at 2007-11-19 16:16 Message generated for change (Comment added) made by jessorensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1834585&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: intel Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: erik (erjomo) Assigned to: Nobody/Anonymous (nobody) Summary: install from iso fails on 2.6.23.8 kernel Initial Comment: Hi, When trying to install debian-testing with kvm, I get as far as "Configuring apt, scanning the mirror" and eventually a crash with a segmentation fault. qemu-img create -f qcow d.img 10G sudo kvm -cdrom debian-testing-i386-netinst.iso -hda d.img -boot d -m 1024 i'm running a custom kernel 2.6.23.8 on an x86-64 core 2 duo machine built whith gcc (Debian 4.2.2-3). kvm version is 52+dfsg-1, kvm-modules-2.6.23.8-x86-64 has 52+dfsg-1+2.6.23.8-x86-64-10.00.Custom When running a distribution kernel (debian 2.6.22-3-amd64) there are no problems. Also running an image once installed works allright under the custom kernel. (I tried Windows XP, debian testing) with --no-kvm flag there is no crash, but an error message 'Bad archive mirror" regards erik -- >Comment By: Jes Sorensen (jessorensen) Date: 2010-07-22 14:19 Message: No updates since my request for info, so presuming the problem has been resolved. -- Comment By: Jes Sorensen (jessorensen) Date: 2010-06-11 10:27 Message: Hi, Looking through old bugs - this is against a very old kernel. Are you still having these problems, or can we close the bug? Thanks, Jes -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1834585&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d regression issue
On Thu, Jul 22, 2010 at 07:11:34PM +0800, Hao, Xudong wrote:
> Gleb,
> This patch does not work either, qemu stoped @ Starting Seabios.
>
And this one?
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2bba22f..b7e7dc0 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -238,9 +238,10 @@ static void assigned_dev_iomem_map_slow(PCIDevice
*pci_dev, int region_num,
DEBUG("%s", "slow map\n");
if (region_num == PCI_ROM_SLOT)
m = cpu_register_io_memory(slow_bar_read, NULL, region);
-else
+else {
m = cpu_register_io_memory(slow_bar_read, slow_bar_write, region);
-cpu_register_physical_memory(e_phys, e_size, m);
+cpu_register_physical_memory(e_phys, e_size, m);
+}
/* MSI-X MMIO page */
if ((e_size > 0) &&
@@ -272,7 +273,8 @@ static void assigned_dev_iomem_map(PCIDevice *pci_dev, int
region_num,
if (region_num == PCI_ROM_SLOT)
flags |= IO_MEM_ROM;
-cpu_register_physical_memory(e_phys, e_size, region->memory_index |
flags);
+if (region_num != PCI_ROM_SLOT)
+ cpu_register_physical_memory(e_phys, e_size,
region->memory_index | flags);
/* deal with MSI-X MMIO page */
if (real_region->base_addr <= r_dev->msix_table_addr &&
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: VT-d regression issue
Gleb Natapov wrote:
> On Thu, Jul 22, 2010 at 07:09:37PM +0800, Hao, Xudong wrote:
>> Patch did not work, qemu stoped @
> Stopped with the same error?
>
Yes.
>>>
>>> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
>>> index 2bba22f..7240985 100644
>>> --- a/hw/device-assignment.c
>>> +++ b/hw/device-assignment.c
>>> @@ -238,9 +238,10 @@ static void
>>> assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
>>> DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
>>> m = cpu_register_io_memory(slow_bar_read, NULL, region); -
>>> else +else {
>>> m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
>>> region); -cpu_register_physical_memory(e_phys, e_size, m);
>>> +cpu_register_physical_memory(e_phys, e_size, m); +}
>>>
>>> /* MSI-X MMIO page */
>>> if ((e_size > 0) &&
>>
>>
>>
>> Thanks,
>> Xudong
Thanks,
Xudong--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: VT-d regression issue
Gleb,
This patch does not work either, qemu stoped @ Starting Seabios.
>
> Can you try this patch for qemu-kvm please?
>
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 2bba22f..7240985 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -238,9 +238,10 @@ static void
> assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
> DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
> m = cpu_register_io_memory(slow_bar_read, NULL, region);
> -else
> +else {
> m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> region); -cpu_register_physical_memory(e_phys, e_size, m);
> +cpu_register_physical_memory(e_phys, e_size, m);
> +}
>
> /* MSI-X MMIO page */
> if ((e_size > 0) &&
Thanks,
Xudong--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d regression issue
On Thu, Jul 22, 2010 at 07:09:37PM +0800, Hao, Xudong wrote:
> Patch did not work, qemu stoped @
Stopped with the same error?
> >
> > diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> > index 2bba22f..7240985 100644
> > --- a/hw/device-assignment.c
> > +++ b/hw/device-assignment.c
> > @@ -238,9 +238,10 @@ static void
> > assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
> > DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
> > m = cpu_register_io_memory(slow_bar_read, NULL, region);
> > -else
> > +else {
> > m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> > region); -cpu_register_physical_memory(e_phys, e_size, m);
> > +cpu_register_physical_memory(e_phys, e_size, m);
> > +}
> >
> > /* MSI-X MMIO page */
> > if ((e_size > 0) &&
>
>
>
> Thanks,
> Xudong
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: VT-d regression issue
Patch did not work, qemu stoped @
> Can you try this patch for qemu-kvm please?
>
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 2bba22f..7240985 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -238,9 +238,10 @@ static void
> assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
> DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
> m = cpu_register_io_memory(slow_bar_read, NULL, region);
> -else
> +else {
> m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> region); -cpu_register_physical_memory(e_phys, e_size, m);
> +cpu_register_physical_memory(e_phys, e_size, m);
> +}
>
> /* MSI-X MMIO page */
> if ((e_size > 0) &&
Thanks,
Xudong--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST PATCH v2 5/5] [RFC] KVM test: add WHQL test definitions to tests_base.cfg.sample
The parameters that define submissions (dd_name_*, dd_data_*, desc_path_*) were collected from manually created submissions. I haven't yet collected the parameters for Windows 2003 and 2008, so for now WHQL tests are disabled for these versions. This patch also adds a comment in tests.cfg.sample, encouraging the user to specify the DTM server's address and ports there. Note that this patch renames WinVista.32sp1 to WinVista.32.sp1, WinVista.32sp2 to WinVista.32.sp2, WinVista.64sp1 to WinVista.64.sp1 and WinVista.64sp2 to WinVista.64.sp2. Changes from v1: - Run all whql_submission tests with -snapshot - Split whql_submission.hdd into 2 variants: a full one and one that only runs a single test (by setting job_filter). Running all tests in a HDD submission takes over 72 hours, so it probably can't be done routinely as part of our regression testing. - Change test_device regex to "qemu harddisk" in whql_submission.hdd. - Update timeouts - Enable WHQL tests for Win2003 Signed-off-by: Michael Goldish --- client/tests/kvm/tests.cfg.sample |8 + client/tests/kvm/tests_base.cfg.sample | 251 +--- 2 files changed, 205 insertions(+), 54 deletions(-) diff --git a/client/tests/kvm/tests.cfg.sample b/client/tests/kvm/tests.cfg.sample index e01406e..cdb7b0a 100644 --- a/client/tests/kvm/tests.cfg.sample +++ b/client/tests/kvm/tests.cfg.sample @@ -73,6 +73,14 @@ variants: only Fedora.13.64 only unattended_install.cdrom boot shutdown +# You may provide information about the DTM server for WHQL tests here: +#whql: +#server_address = 10.20.30.40 +#server_shell_port = 10022 +#server_file_transfer_port = 10023 +# Note that the DTM server must run rss.exe (available under deps/), +# preferably with administrator privileges. + # Uncomment the following lines to enable abort-on-error mode: #abort_on_error = yes #kill_vm.* ?= no diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index d0b8acb..f631184 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -285,6 +285,90 @@ variants: iozone_cmd = "D:\IOzone\iozone.exe -a" iozone_timeout = 3600 +- @whql: install setup unattended_install.cdrom +nic_mode = tap +# Replace this with the address of an installed DTM server +server_address = 10.20.30.40 +# The server should run rss.exe like a regular Windows VM, preferably +# with administrator privileges (or at least with permission to write +# to the DTM studio directory) +server_shell_port = 10022 +server_file_transfer_port = 10023 +server_studio_path = %programfiles%\Microsoft Driver Test Manager\Studio +wtt_services = wttsvc +variants: +- whql_client_install: +type = whql_client_install +dsso_delete_machine_binary = deps/whql_delete_machine_15.exe +# The username and password are required for accessing the DTM client +# installer binary shared by the server +server_username = administrator +server_password = 1q2w3eP +# This path refers to a shared directory on the server +# (the final cmd will be something like \\servername\DTMInstall\...) +install_cmd = \DTMInstall\Client\Setup.exe /passive +install_timeout = 3600 +- whql_submission:whql_client_install +type = whql_submission +extra_params += " -snapshot" +dsso_test_binary = deps/whql_submission_15.exe +test_timeout = 3600 +device_data = cat0 cat1 cat2 cat3 logoarch logoos whqlos whqlqual prog desc filter virt +descriptors = desc1 desc2 desc3 +# DeviceData names +dd_name_cat0 = Category +dd_name_cat1 = Category +dd_name_cat2 = Category +dd_name_cat3 = Category +dd_name_logoarch = LogoProcessorArchitecture +dd_name_logoos = LogoOperatingSystem +dd_name_whqlos = WhqlOs +dd_name_whqlqual = WhqlQualification +dd_name_prog = LogoProgramId +dd_name_desc = LogoProgramDescription +dd_name_filter = WDKFilterAttribute +dd_name_virt = ParaVirtualizationDriver +# Common DeviceData data +dd_data_filter = FilterIfNoInf +dd_data_virt = True +variants: +- keyboard: +# test_device is a regular expression that should match a device's +# name as it appears in device mana
[KVM-AUTOTEST PATCH v2 4/5] [RFC] KVM test: add whql_client_install test
whql_client_install installs the DTM client on a guest. It requires a
functioning external DTM server which runs rss.exe like regular Windows VMs.
Signed-off-by: Michael Goldish
---
client/tests/kvm/tests/whql_client_install.py | 110 +
1 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/tests/whql_client_install.py
diff --git a/client/tests/kvm/tests/whql_client_install.py
b/client/tests/kvm/tests/whql_client_install.py
new file mode 100644
index 000..f46939e
--- /dev/null
+++ b/client/tests/kvm/tests/whql_client_install.py
@@ -0,0 +1,110 @@
+import logging, time, os, re
+from autotest_lib.client.common_lib import error
+import kvm_subprocess, kvm_test_utils, kvm_utils, rss_file_transfer
+
+
+def run_whql_client_install(test, params, env):
+"""
+WHQL DTM client installation:
+1) Log into the guest (the client machine) and into a DTM server machine
+2) Stop the DTM client service (wttsvc) on the client machine
+3) Delete the client machine from the server's data store
+4) Rename the client machine (give it a randomly generated name)
+5) Move the client machine into the server's workgroup
+6) Reboot the client machine
+7) Install the DTM client software
+
+@param test: kvm test object
+@param params: Dictionary with the test parameters
+@param env: Dictionary with test environment.
+"""
+vm = kvm_test_utils.get_living_vm(env, params.get("main_vm"))
+session = kvm_test_utils.wait_for_login(vm, 0, 240)
+
+# Collect test params
+server_address = params.get("server_address")
+server_shell_port = int(params.get("server_shell_port"))
+server_file_transfer_port = int(params.get("server_file_transfer_port"))
+server_studio_path = params.get("server_studio_path", "%programfiles%\\ "
+"Microsoft Driver Test Manager\\Studio")
+server_username = params.get("server_username")
+server_password = params.get("server_password")
+dsso_delete_machine_binary = params.get("dsso_delete_machine_binary",
+"deps/whql_delete_machine_15.exe")
+dsso_delete_machine_binary = kvm_utils.get_path(test.bindir,
+dsso_delete_machine_binary)
+install_timeout = float(params.get("install_timeout", 600))
+install_cmd = params.get("install_cmd")
+wtt_services = params.get("wtt_services")
+
+# Stop WTT service(s) on client
+for svc in wtt_services.split():
+kvm_test_utils.stop_windows_service(session, svc)
+
+# Copy dsso_delete_machine_binary to server
+rss_file_transfer.upload(server_address, server_file_transfer_port,
+ dsso_delete_machine_binary, server_studio_path,
+ timeout=60)
+
+# Open a shell session with server
+server_session = kvm_utils.remote_login("nc", server_address,
+server_shell_port, "", "",
+session.prompt, session.linesep)
+
+# Get server and client information
+cmd = "echo %computername%"
+server_name = server_session.get_command_output(cmd).strip()
+client_name = session.get_command_output(cmd).strip()
+cmd = "wmic computersystem get workgroup"
+server_workgroup = server_session.get_command_output(cmd).strip()
+
+# Delete the client machine from the server's data store (if it's there)
+server_session.get_command_output("cd %s" % server_studio_path)
+cmd = "%s %s %s" % (os.path.basename(dsso_delete_machine_binary),
+server_name, client_name)
+server_session.get_command_output(cmd, print_func=logging.info)
+server_session.close()
+
+# Rename the client machine
+client_name = "autotest_%s" % kvm_utils.generate_random_string(4)
+logging.info("Renaming client machine to '%s'" % client_name)
+cmd = ('wmic computersystem where name="%%computername%%" rename name="%s"'
+ % client_name)
+s = session.get_command_status(cmd, timeout=600)
+if s != 0:
+raise error.TestError("Could not rename the client machine")
+
+# Join the server's workgroup
+logging.info("Joining workgroup '%s'" % server_workgroup)
+cmd = ('wmic computersystem where name="%%computername%%" call '
+ 'joindomainorworkgroup name="%s"' % server_workgroup)
+s = session.get_command_status(cmd, timeout=600)
+if s != 0:
+raise error.TestError("Could not change the client's workgroup")
+
+# Reboot
+session = kvm_test_utils.reboot(vm, session)
+
+# Access shared resources on the server machine
+logging.info("Attempting to access remote share on server")
+cmd = r"net use \\%s /user:%s %s" % (server_name, server_username,
+ server_password)
+end_time = time.time() + 120
+while time.time() <
[KVM-AUTOTEST PATCH v2 3/5] [RFC] KVM test: add whql_submission test
whql_submission runs a submission on a given device. It requires a
functioning external DTM server which runs rss.exe like regular Windows VMs,
preferably with administrator permissions.
The submission is defined by descriptors and device_data objects, which are
specified in the config file(s). All jobs of the submission are executed.
When all jobs complete, or when the timeout expires, HTML reports are generated
and copied to test.debugdir (client/results/default/kvm...whql_submission/debug)
and the raw test logs (wtl or xml files) are copied to test.debugdir as well.
Changes from v1:
- Send job_filter to the automation program to let it know which tests to
allow. job_filter defaults to .*, which means all tests of the submission
are run.
- Instead of determining test status by the 'pass', 'fail' and 'notrun' values,
determine it by the 'status' string (e.g. 'Investigate', 'InProgress').
- Kill the client VM if the tests don't complete on time.
- In the final results summary display the job ID of each job.
Signed-off-by: Michael Goldish
---
client/tests/kvm/tests/whql_submission.py | 188 +
1 files changed, 188 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/tests/whql_submission.py
diff --git a/client/tests/kvm/tests/whql_submission.py
b/client/tests/kvm/tests/whql_submission.py
new file mode 100644
index 000..1fe27c9
--- /dev/null
+++ b/client/tests/kvm/tests/whql_submission.py
@@ -0,0 +1,188 @@
+import logging, time, os, re
+from autotest_lib.client.common_lib import error
+import kvm_subprocess, kvm_test_utils, kvm_utils, rss_file_transfer
+
+
+def run_whql_submission(test, params, env):
+"""
+WHQL submission test:
+1) Log into the guest (the client machine) and into a DTM server machine
+2) Copy the automation program binary (dsso_test_binary) to the server
machine
+3) Run the automation program
+4) Pass the program all relevant parameters (e.g. device_data)
+5) Wait for the program to terminate
+6) Parse and report job results
+(logs and HTML reports are placed in test.bindir)
+
+@param test: kvm test object
+@param params: Dictionary with the test parameters
+@param env: Dictionary with test environment.
+"""
+vm = kvm_test_utils.get_living_vm(env, params.get("main_vm"))
+session = kvm_test_utils.wait_for_login(vm, 0, 240)
+
+# Collect parameters
+server_address = params.get("server_address")
+server_shell_port = int(params.get("server_shell_port"))
+server_file_transfer_port = int(params.get("server_file_transfer_port"))
+server_studio_path = params.get("server_studio_path", "%programfiles%\\ "
+"Microsoft Driver Test Manager\\Studio")
+dsso_test_binary = params.get("dsso_test_binary",
+ "deps/whql_submission_15.exe")
+dsso_test_binary = kvm_utils.get_path(test.bindir, dsso_test_binary)
+test_device = params.get("test_device")
+job_filter = params.get("job_filter", ".*")
+test_timeout = float(params.get("test_timeout", 600))
+wtt_services = params.get("wtt_services")
+
+# Restart WTT service(s) on the client
+logging.info("Restarting WTT services on client")
+for svc in wtt_services.split():
+kvm_test_utils.stop_windows_service(session, svc)
+for svc in wtt_services.split():
+kvm_test_utils.start_windows_service(session, svc)
+
+# Copy dsso_test_binary to the server
+rss_file_transfer.upload(server_address, server_file_transfer_port,
+ dsso_test_binary, server_studio_path, timeout=60)
+
+# Open a shell session with the server
+server_session = kvm_utils.remote_login("nc", server_address,
+server_shell_port, "", "",
+session.prompt, session.linesep)
+
+# Get the computer names of the server and client
+cmd = "echo %computername%"
+server_name = server_session.get_command_output(cmd).strip()
+client_name = session.get_command_output(cmd).strip()
+session.close()
+
+# Run the automation program on the server
+server_session.get_command_output("cd %s" % server_studio_path)
+cmd = "%s %s %s %s %s %s" % (os.path.basename(dsso_test_binary),
+ server_name,
+ client_name,
+ "%s_pool" % client_name,
+ "%s_submission" % client_name,
+ test_timeout)
+server_session.sendline(cmd)
+
+# Helper function: wait for a given prompt and raise an exception if an
+# error occurs
+def find_prompt(prompt):
+m, o = server_session.read_until_last_line_matches(
+[prompt, server_session.prompt], print_func=logging.info,
+timeout=600)
+if m != 0:
+errors = re.findall("^Error
[KVM-AUTOTEST PATCH v2 2/5] [RFC] KVM test: DTM machine deletion tool for WHQL tests
This C# program should run on a DTM server. It's used by the
whql_client_install test to delete the client machine from the server's data
store (if listed there) prior to client installation. This seems to be
necessary to prevent trouble during testing (like failure to contact the client
machine).
Note: the binary is copied to the server at run time, so it doesn't need to be
packaged in winutils.iso.
Signed-off-by: Michael Goldish
---
client/tests/kvm/deps/whql_delete_machine_15.cs | 82 ++
client/tests/kvm/deps/whql_delete_machine_15.exe | Bin 0 -> 5632 bytes
2 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/deps/whql_delete_machine_15.cs
create mode 100644 client/tests/kvm/deps/whql_delete_machine_15.exe
diff --git a/client/tests/kvm/deps/whql_delete_machine_15.cs
b/client/tests/kvm/deps/whql_delete_machine_15.cs
new file mode 100644
index 000..1d78a6d
--- /dev/null
+++ b/client/tests/kvm/deps/whql_delete_machine_15.cs
@@ -0,0 +1,82 @@
+// DTM machine deletion tool
+// Author: Michael Goldish
+// Based on sample code by Microsoft.
+
+using System;
+using System.Collections.Generic;
+using System.Text.RegularExpressions;
+using Microsoft.DistributedAutomation.DeviceSelection;
+using Microsoft.DistributedAutomation.SqlDataStore;
+
+namespace automate0
+{
+class AutoJob
+{
+static int Main(string[] args)
+{
+if (args.Length != 2)
+{
+Console.WriteLine("Error: incorrect number of command line
arguments");
+Console.WriteLine("Usage: {0} serverName clientName",
+System.Environment.GetCommandLineArgs()[0]);
+return 1;
+}
+string serverName = args[0];
+string clientName = args[1];
+
+try
+{
+// Initialize DeviceScript and connect to data store
+Console.WriteLine("Initializing DeviceScript object");
+DeviceScript script = new DeviceScript();
+Console.WriteLine("Connecting to data store");
+script.ConnectToNamedDataStore(serverName);
+
+// Find the client machine
+IResourcePool rootPool = script.GetResourcePoolByName("$");
+Console.WriteLine("Looking for client machine '{0}'",
clientName);
+IResource machine = rootPool.GetResourceByName(clientName);
+if (machine == null)
+{
+Console.WriteLine("Client machine not found");
+return 0;
+}
+Console.WriteLine("Client machine '{0}' found ({1}, {2})",
+clientName, machine.OperatingSystem,
machine.ProcessorArchitecture);
+
+// Change the client machine's status to 'unsafe'
+Console.WriteLine("Changing the client machine's status to
'Unsafe'");
+try
+{
+machine.ChangeResourceStatus("Unsafe");
+}
+catch (Exception e)
+{
+Console.WriteLine("Warning: " + e.Message);
+}
+while (machine.Status != "Unsafe")
+{
+try
+{
+machine = rootPool.GetResourceByName(clientName);
+}
+catch (Exception e)
+{
+Console.WriteLine("Warning: " + e.Message);
+}
+System.Threading.Thread.Sleep(1000);
+}
+
+// Delete the client machine from datastore
+Console.WriteLine("Deleting client machine from data store");
+script.DeleteResource(machine.Id);
+return 0;
+}
+catch (Exception e)
+{
+Console.WriteLine("Error: " + e.Message);
+return 1;
+}
+}
+}
+}
diff --git a/client/tests/kvm/deps/whql_delete_machine_15.exe
b/client/tests/kvm/deps/whql_delete_machine_15.exe
new file mode 100644
index
..7f571345dd04b1871c5156556791d97ca2564419
GIT binary patch
literal 5632
zcmeHLO>i...@if?n$a(>u_XV+mhI8nE=x|dT04dqW7)gX%Fa5HCA5;91X1?vY-=^n
z?98TTR!A`>IwVwaq3oi#_yUKxfEy61NI?My2%KD%V=g$Zf+40K%bKHGj-Hz;=oPmlQe9o~gQ4o_aiR&WjZXjm>_pw#U5aR%
zwHVPBU@&pJe*}Y$o5dXR(-?Db4_DX=&0i-rA1w-wCcHA6*=J?JdksUYVk)1a;%kS5jJQ$B}k$yV%P`%Oa=unR|fle4w...@1jnpzx&79p)7g>&D
zLU!TM~R?RIWZxf4X{jvb+F_;uVu
zRJ{G~pzlUUV8}1g?Et0^Ft_5LVInx5LEjtjX!{}qJ7D<8XyN>*7Kp2JvwSR-PJJ%@
z{ITa*sGV$#KZ4wWujB0FJT0LgDEQKH${usPiB0`2ZTk%vVM%aX%OR9Sp5g>r!UYZ?Vy4ODXZ{VdRZF={DyX%
z^7LKpBz=i~tYt91hmoanfIkG!%XA+Y1E0?XS(J{<0RQ<2W3rKpfTto~fu8xuZsd_I
zrjP{>V=sLT;~wO|py(QHXn({y$YVgzXg~p4vvOkH7o>tIrzYJ}%@(IAH#<2iJU=B?
z1Z8W!dmj5~V6GUxNK?f#U1?iIDy(|GsL)jLiZFeeG%SZwrteBJBu+~}P30
[KVM-AUTOTEST PATCH v2 1/5] [RFC] KVM test: DTM automation program for WHQL tests
This C# program should run on a DTM/WHQL server. It's used by the
whql_submission test to schedule and monitor device submission jobs.
Note: the binary is copied to the server at run time, so it doesn't need to be
packaged in winutils.iso.
Changes from v1:
- Take a job filter regex from the user, and run only the jobs whose names
match the regex. This is useful for running individual tests instead of
whole submissions which can take many hours to run.
- When test execution completes set the client machine's state to Unsafe and
then Reset.
- Instead of looking for the requested test device and failing immediately if
it isn't found, allow up to 2 minutes for it to show up.
- Add the job ID of each job to the result list printed to stdout.
Signed-off-by: Michael Goldish
---
client/tests/kvm/deps/whql_submission_15.cs | 289 ++
client/tests/kvm/deps/whql_submission_15.exe | Bin 0 -> 10240 bytes
2 files changed, 289 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/deps/whql_submission_15.cs
create mode 100644 client/tests/kvm/deps/whql_submission_15.exe
diff --git a/client/tests/kvm/deps/whql_submission_15.cs
b/client/tests/kvm/deps/whql_submission_15.cs
new file mode 100644
index 000..bf6e136
--- /dev/null
+++ b/client/tests/kvm/deps/whql_submission_15.cs
@@ -0,0 +1,289 @@
+// DTM submission automation program
+// Author: Michael Goldish
+// Based on sample code by Microsoft.
+
+// Note: this program has only been tested with DTM version 1.5.
+// It might fail to work with other versions, specifically because it uses
+// a few undocumented methods/attributes.
+
+using System;
+using System.Collections.Generic;
+using System.Text.RegularExpressions;
+using Microsoft.DistributedAutomation.DeviceSelection;
+using Microsoft.DistributedAutomation.SqlDataStore;
+
+namespace automate0
+{
+class AutoJob
+{
+static int Main(string[] args)
+{
+if (args.Length != 5)
+{
+Console.WriteLine("Error: incorrect number of command line
arguments");
+Console.WriteLine("Usage: {0} serverName clientName
machinePoolName submissionName timeout",
+System.Environment.GetCommandLineArgs()[0]);
+return 1;
+}
+string serverName = args[0];
+string clientName = args[1];
+string machinePoolName = args[2];
+string submissionName = args[3];
+double timeout = Convert.ToDouble(args[4]);
+
+try
+{
+// Initialize DeviceScript and connect to data store
+Console.WriteLine("Initializing DeviceScript object");
+DeviceScript script = new DeviceScript();
+Console.WriteLine("Connecting to data store");
+
+script.ConnectToNamedDataStore(serverName);
+
+// Find client machine
+IResourcePool rootPool = script.GetResourcePoolByName("$");
+Console.WriteLine("Looking for client machine '{0}'",
clientName);
+IResource machine = null;
+while (true)
+{
+try
+{
+machine = rootPool.GetResourceByName(clientName);
+}
+catch (Exception e)
+{
+Console.WriteLine("Warning: " + e.Message);
+}
+// Make sure the machine is valid
+if (machine != null &&
+machine.OperatingSystem != null &&
+machine.OperatingSystem.Length > 0 &&
+machine.ProcessorArchitecture != null &&
+machine.ProcessorArchitecture.Length > 0 &&
+machine.GetDevices().Length > 0)
+break;
+System.Threading.Thread.Sleep(1000);
+}
+Console.WriteLine("Client machine '{0}' found ({1}, {2})",
+clientName, machine.OperatingSystem,
machine.ProcessorArchitecture);
+
+// Create machine pool and add client machine to it
+// (this must be done because jobs cannot be scheduled for
machines in the
+// default pool)
+try
+{
+script.CreateResourcePool(machinePoolName,
rootPool.ResourcePoolId);
+}
+catch (Exception e)
+{
+Console.WriteLine("Warning: " + e.Message);
+}
+IResourcePool newPool =
script.GetResourcePoolByName(machinePoolName);
+Console.WriteLine("Moving the client machine to pool '{0}'",
machinePoolName);
+machine.ChangeResourcePool(newPool);
+
+// Reset client machine
+if (machine.S
about using vmcall instruction
an module is executed in guest using vmcall instruction. then host
handler the vmcall exit and read the registers value. but ax,cx,dx get
the correct values while bx and si get the worong. what is the
problem.
code in guest is :
__asm__ ("mov $10,%ax");
__asm__ ("mov $20,%bx");
__asm__ ("mov $30,%cx");
__asm__ ("mov $40,%dx");
__asm__ ("mov $50,%si");
__asm__ ("vmcall");
host output :
HYPER CALL IS CALLED AND THE NR IS 10,bx is -526778348,cx is 30,dx is
40,si is -1017839566
so ax(NR) ,cx,dx values are correct .but bx and si values are wrong.why?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Swap usage with KVM
Hi, David.
On Tuesday, 20 July 2010 21:18:09 +0200,
David Weber wrote:
> > Yes, we are using Virtio drivers for networking and storage in both VMs
> > with cache=none. Both VMs are running Linux 2.6.32-bpo.5-amd64 from
> > Lenny Backports repositories. For VMHost, we are using a stable version
> > of KVM with Linux 2.6.32.12 compiled from source code of kernel.org and
> > qemu-kvm 0.12.3 compiled with the source code obtained from the official
> > site of KVM.
> Afaik this should be this bug
> http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
>
> try upgrading to 0.12.4 or backport this commit
> http://git.kernel.org/?p=virt/kvm/qemu-
> kvm.git;a=commit;h=012d4869c1eb195e83f159ed7b2bced33f37f960
Interesting... I'll try upgrading to qemu-kvm 0.12.4.
Marcelo Tosatti also recommended me to apply this patch I'm attaching.
Someone could confirm whether this is already included in Linux stable?
Thanks for your reply.
Regards,
Daniel
--
Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598
commit 6316e1c8c6af6ccb55ff8564231710660608f46c
Author: Rik van Riel
Date: Wed Feb 3 16:11:03 2010 -0500
KVM: VMX: emulate accessed bit for EPT
Currently KVM pretends that pages with EPT mappings never got
accessed. This has some side effects in the VM, like swapping
out actively used guest pages and needlessly breaking up actively
used hugepages.
We can avoid those very costly side effects by emulating the
accessed bit for EPT PTEs, which should only be slightly costly
because pages pass through page_referenced infrequently.
TLB flushing is taken care of by kvm_mmu_notifier_clear_flush_young().
This seems to help prevent KVM guests from being swapped out when
they should not on my system.
Signed-off-by: Rik van Riel
Signed-off-by: Avi Kivity
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 913ef4b..b8da671 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -838,9 +838,15 @@ static int kvm_age_rmapp(struct kvm *kvm, unsigned long *rmapp,
u64 *spte;
int young = 0;
- /* always return old for EPT */
+ /*
+ * Emulate the accessed bit for EPT, by checking if this page has
+ * an EPT mapping, and clearing it if it does. On the next access,
+ * a new EPT mapping will be established.
+ * This has some overhead, but not as much as the cost of swapping
+ * out actively used pages or breaking up actively used hugepages.
+ */
if (!shadow_accessed_mask)
- return 0;
+ return kvm_unmap_rmapp(kvm, rmapp, data);
spte = rmap_next(kvm, rmapp, NULL);
while (spte) {
signature.asc
Description: Digital signature
Re: VT-d regression issue
On Thu, Jul 22, 2010 at 04:47:12PM +0800, Hao, Xudong wrote:
> [r...@vt-nhm1 ~]# lspci -vv -s 01:00.0
> 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet
> Controller (Copper) (rev 06)
> Subsystem: Intel Corporation PRO/1000 PT Desktop Adapter
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Interrupt: pin A routed to IRQ 16
> Region 0: Memory at d3c2 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at d3c0 (32-bit, non-prefetchable) [size=128K]
> Region 2: I/O ports at 5000 [size=32]
> Expansion ROM at d3e0 [size=128K]
> Capabilities: [c8] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [d0] MSI: Mask- 64bit+ Count=1/1 Enable-
> Address: fee00418 Data:
> Capabilities: [e0] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns,
> L1 <64us
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+
> TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0
> <4us, L1 <64us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> Capabilities: [100] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
> Capabilities: [140] Device Serial Number 82-ff-04-ff-ff-21-1b-00
> Kernel driver in use: pci-stub
> Kernel modules: e1000e
>
Can you try this patch for qemu-kvm please?
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2bba22f..7240985 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -238,9 +238,10 @@ static void assigned_dev_iomem_map_slow(PCIDevice
*pci_dev, int region_num,
DEBUG("%s", "slow map\n");
if (region_num == PCI_ROM_SLOT)
m = cpu_register_io_memory(slow_bar_read, NULL, region);
-else
+else {
m = cpu_register_io_memory(slow_bar_read, slow_bar_write, region);
-cpu_register_physical_memory(e_phys, e_size, m);
+cpu_register_physical_memory(e_phys, e_size, m);
+}
/* MSI-X MMIO page */
if ((e_size > 0) &&
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: VT-d regression issue
[r...@vt-nhm1 ~]# lspci -vv -s 01:00.0 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: Intel Corporation PRO/1000 PT Desktop Adapter Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- On Thu, Jul 22, 2010 at 03:57:55PM +0800, Hao, Xudong wrote: >> Hi, all >> >> On KVM commit cb7eaecb3389c7fa2490ea1bee8f10cfa5df30d4, I met a >> kvm_run return fasle when assign additional NIC device to KVM guest, >> but onboard NIC works fine. >> >> command: qemu-system-x86_64 -m 256 -smp 2 -device >> pci-assign,host=01:00.0 -net none -hda /image/path/guest.img > Which version of qemu-kvm is this? > >> host print: >> kvm_run: Bad address >> kvm_run returned -14 >> >> platform: Westmere-HEDT >> NIC device: 01:00.0 Ethernet controller: Intel Corporation 82572EI >> Gigabit Ethernet Controller (Copper) (rev 06) >> > lspci -vv -s 01:00.0? > >> VT-d works fine on KVM commit >> 8dea5648467102184c65d61cf2be6e0fbfa41060 and new qemu-kvm. >> >> https://bugzilla.kernel.org/show_bug.cgi?id=16437 >> >> >> Best Regards, >> Xudong Hao >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks, Xudong-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d regression issue
On Thu, Jul 22, 2010 at 03:57:55PM +0800, Hao, Xudong wrote: > Hi, all > > On KVM commit cb7eaecb3389c7fa2490ea1bee8f10cfa5df30d4, I met a kvm_run > return fasle when assign additional NIC device to KVM guest, but onboard NIC > works fine. > > command: qemu-system-x86_64 -m 256 -smp 2 -device pci-assign,host=01:00.0 > -net none -hda /image/path/guest.img Which version of qemu-kvm is this? > host print: > kvm_run: Bad address > kvm_run returned -14 > > platform: Westmere-HEDT > NIC device: 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit > Ethernet Controller (Copper) (rev 06) > lspci -vv -s 01:00.0? > VT-d works fine on KVM commit 8dea5648467102184c65d61cf2be6e0fbfa41060 and > new qemu-kvm. > > https://bugzilla.kernel.org/show_bug.cgi?id=16437 > > > Best Regards, > Xudong Hao > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
VT-d regression issue
Hi, all On KVM commit cb7eaecb3389c7fa2490ea1bee8f10cfa5df30d4, I met a kvm_run return fasle when assign additional NIC device to KVM guest, but onboard NIC works fine. command: qemu-system-x86_64 -m 256 -smp 2 -device pci-assign,host=01:00.0 -net none -hda /image/path/guest.img host print: kvm_run: Bad address kvm_run returned -14 platform: Westmere-HEDT NIC device: 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) VT-d works fine on KVM commit 8dea5648467102184c65d61cf2be6e0fbfa41060 and new qemu-kvm. https://bugzilla.kernel.org/show_bug.cgi?id=16437 Best Regards, Xudong Hao -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
