Re: [kvm-ppc-devel] [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync

Re: [kvm-ppc-devel] [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync

[Hollis Blanchard]

On Thu, 2007-12-13 at 20:36 +0100, Christian Ehrhardt wrote:
> @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t
> addr, uint8_t *buf,
>                      phys_ram_dirty[addr1 >> TARGET_PAGE_BITS] |>                          (0xff & ~CODE_DIRTY_FLAG);
>                  }
> -#ifdef __ia64__
> -		kvm_sync_icache((unsigned long)ptr, l);
> +#ifdef USE_KVM
> +		flush_icache_range((unsigned long)ptr, ((unsigned long)ptr)+l);
>  #endif
>              }
>          } else {

A comment to explain why the icache needs flushing only in the KVM case
would be useful. Other than that I'm fine with it.

Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync

[Zhang, Xiantao]

>  #include "qemu-kvm.h"
>  #endif
>  #if defined(CONFIG_USER_ONLY)
> @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t
>                      addr, uint8_t *buf, phys_ram_dirty[addr1 >>
>                          TARGET_PAGE_BITS] |= (0xff &
>                  ~CODE_DIRTY_FLAG); }
> -#ifdef __ia64__
> -		kvm_sync_icache((unsigned long)ptr, l);
> +#ifdef USE_KVM
> +		flush_icache_range((unsigned long)ptr, ((unsigned
long)ptr)+l);

Are you sure ia64 implement this function for applications ? I didn't
find it at my side, so I write it. 

If not, maybe you can change the patch like the following :)

 in target-ia64/cpu.h

#define flush_icache_range(start, end)  kvm_sync_icache(start,
(end)-(start))

Or upgrade kvm_sync_icach to comply with flush_icache_range, and change
the name to flush_icache_range. 

Thank you!
Xiantao

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync

[Christian Ehrhardt]

Zhang, Xiantao wrote:
>Christian Ehrhardt wrote:
<[...]
>> @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t
>>                      addr, uint8_t *buf, phys_ram_dirty[addr1 >>
>>                          TARGET_PAGE_BITS] |= (0xff &
>>                  ~CODE_DIRTY_FLAG); }
>> -#ifdef __ia64__
>> -		kvm_sync_icache((unsigned long)ptr, l);
>> +#ifdef USE_KVM
>> +		flush_icache_range((unsigned long)ptr, ((unsigned
> long)ptr)+l);
> 
> Are you sure ia64 implement this function for applications ? I didn't
> find it at my side, so I write it. 
What do you mean with "implement it for applications" ?
Take a look at dyngen.h - it starts with the comment "dyngen helpers" 
and contains a lot of static functions to use them where you need.
I don't see anything obvious that would prevent these functions from
being built and the file has no own include statements which may 
change that. Therefor the include "dyngen.h" in the USE_KVM case
should be enough to have this function available for
cpu_physical_memory_rw in exec.c where we need it.
[...]
> Xiantao

---

Hollis Blanchard wrote:
> A comment to explain why the icache needs flushing only in the KVM case
> would be useful. Other than that I'm fine with it.
> 
> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
AFAIK Plain qemu does not directly execute guest code on the processor,
so the icache is not an issue for it.
Qemu itself has the flush_icache_range function only as helper for the
dynamic code generation.
But we may now write executable guest code with our intercepted mmio
handling that is directly executed when switching back to the guest
context, therefore we need that invalidation in the kvm case.

For the case that I'm overlooking something in plain qemu, so that it
might need it too I add qemu-devel@nongnu.org for comments from there,
but currently I think to have it in #ifdef USE_KVM is the right way.


P.S. Hollis did you mean you would like to see a comment in the code
where that call takes place?

-- 

Grüsse / regards, 
Christian Ehrhardt

IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
Ehrhardt@linux.vnet.ibm.com
Ehrhardt@de.ibm.com

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen 
Geschäftsführung: Herbert Kircher 
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync

[Zhang, Xiantao]

Christian Ehrhardt wrote:
> Zhang, Xiantao wrote:
>> Christian Ehrhardt wrote:
> <[...]
>>> @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t
>>>                      addr, uint8_t *buf, phys_ram_dirty[addr1 >>
>>>                          TARGET_PAGE_BITS] |= (0xff &
>>>                  ~CODE_DIRTY_FLAG); }
>>> -#ifdef __ia64__
>>> -		kvm_sync_icache((unsigned long)ptr, l);
>>> +#ifdef USE_KVM
>>> +		flush_icache_range((unsigned long)ptr, ((unsigned
long)ptr)+l);
>> 
>> Are you sure ia64 implement this function for applications ? I didn't
>> find it at my side, so I write it.
> What do you mean with "implement it for applications" ?
> Take a look at dyngen.h - it starts with the comment "dyngen helpers"
> and contains a lot of static functions to use them where you need.
> I don't see anything obvious that would prevent these functions from
> being built and the file has no own include statements which may
> change that. Therefor the include "dyngen.h" in the USE_KVM case
> should be enough to have this function available for
> cpu_physical_memory_rw in exec.c where we need it.

Good! I didn't notice this definition. Originally, I think you mean it
is a library functions. :) 

> 
> Hollis Blanchard wrote:
>> A comment to explain why the icache needs flushing only in the KVM
>> case would be useful. Other than that I'm fine with it.
>> 
>> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
> AFAIK Plain qemu does not directly execute guest code on the
> processor, so the icache is not an issue for it.
> Qemu itself has the flush_icache_range function only as helper for the
> dynamic code generation.
> But we may now write executable guest code with our intercepted mmio
> handling that is directly executed when switching back to the guest
> context, therefore we need that invalidation in the kvm case.
> 
> For the case that I'm overlooking something in plain qemu, so that it
> might need it too I add qemu-devel@nongnu.org for comments from there,
> but currently I think to have it in #ifdef USE_KVM is the right way.
> 
> 
> P.S. Hollis did you mean you would like to see a comment in the code
> where that call takes place?


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync

[Hollis Blanchard]

On Fri, 2007-12-14 at 10:07 +0100, Christian Ehrhardt wrote:
> 
> Hollis Blanchard wrote:
> > A comment to explain why the icache needs flushing only in the KVM
> case
> > would be useful. Other than that I'm fine with it.
> > 
> > Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
> AFAIK Plain qemu does not directly execute guest code on the
> processor,
> so the icache is not an issue for it.
> Qemu itself has the flush_icache_range function only as helper for the
> dynamic code generation.
> But we may now write executable guest code with our intercepted mmio
> handling that is directly executed when switching back to the guest
> context, therefore we need that invalidation in the kvm case.
> 
> For the case that I'm overlooking something in plain qemu, so that it
> might need it too I add qemu-devel@nongnu.org for comments from there,
> but currently I think to have it in #ifdef USE_KVM is the right way.
> 
> 
> P.S. Hollis did you mean you would like to see a comment in the code
> where that call takes place?

Yes! Hopefully much shorter than this email... :-P

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync

[Christian Ehrhardt]

Hollis Blanchard wrote:
> On Fri, 2007-12-14 at 10:07 +0100, Christian Ehrhardt wrote:
>> Hollis Blanchard wrote:
>>> A comment to explain why the icache needs flushing only in the KVM
>> case
>>> would be useful. Other than that I'm fine with it.
>>>
>>> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
>> AFAIK Plain qemu does not directly execute guest code on the
>> processor,
>> so the icache is not an issue for it.
>> Qemu itself has the flush_icache_range function only as helper for the
>> dynamic code generation.
>> But we may now write executable guest code with our intercepted mmio
>> handling that is directly executed when switching back to the guest
>> context, therefore we need that invalidation in the kvm case.
>>
>> For the case that I'm overlooking something in plain qemu, so that it
>> might need it too I add qemu-devel@nongnu.org for comments from there,
>> but currently I think to have it in #ifdef USE_KVM is the right way.
>>
>>
>> P.S. Hollis did you mean you would like to see a comment in the code
>> where that call takes place?
> 
> Yes! Hopefully much shorter than this email... :-P
> 
comment added, rebased and resent together with a updated mmio
callback simplification patch - I hope I didn't overlook a response
to the mmio callback thread again this time ;-)

-- 

Grüsse / regards, 
Christian Ehrhardt

IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
Ehrhardt@linux.vnet.ibm.com
Ehrhardt@de.ibm.com

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen 
Geschäftsführung: Herbert Kircher 
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

[PATCH][UPDATE] kvm-userspace: sync icache for more architectures

[Christian Ehrhardt]

Subject: [PATCH][UPDATE] kvm-userspace: sync icache for more architectures
From: Christian Ehrhardt <ehrhardt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

A ia64 patch introduced kvm_sync_icache within a ifdef __ia64__, but the 
concept of split caches is not bound to ia64. This patch replaces the the 
call to kvm_synch_icache by the flush_icache_range function
that is already available in qemu for ia64 and ppc (noop for x86). 
The call now depends on USE_KVM.

Signed-off-by: Christian Ehrhardt <ehrhardt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

diff --git a/qemu/exec.c b/qemu/exec.c
index 8b6a2f6..7371cc7 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -35,6 +35,7 @@
 #include "cpu.h"
 #include "exec-all.h"
 #ifdef USE_KVM
+#include "dyngen.h"
 #include "qemu-kvm.h"
 #endif
 #if defined(CONFIG_USER_ONLY)
@@ -2600,8 +2601,10 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                     phys_ram_dirty[addr1 >> TARGET_PAGE_BITS] |=
                         (0xff & ~CODE_DIRTY_FLAG);
                 }
-#ifdef __ia64__
-		kvm_sync_icache((unsigned long)ptr, l);
+#ifdef USE_KVM
+		/* qemu doesn't execute guest code directly, but kvm does
+		   therefore fluch instruction caches */
+		flush_icache_range((unsigned long)ptr, ((unsigned long)ptr)+l);
 #endif
             }
         } else {
diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c
index 03df73d..cf76f35 100644
--- a/qemu/hw/ipf.c
+++ b/qemu/hw/ipf.c
@@ -273,17 +273,6 @@ static void pc_init_ne2k_isa(NICInfo *nd, qemu_irq *pic)
 #ifdef USE_KVM
 extern kvm_context_t kvm_context;
 extern int kvm_allowed;
-
-void kvm_sync_icache(unsigned long address, int len)
-{
-	int l;
-
-	for(l = 0; l < (len + 32); l += 32)
-		__ia64_fc(address + l);
-
-	ia64_sync_i();
-	ia64_srlz_i();
-}
 #endif
 
 static void main_cpu_reset(void *opaque)
diff --git a/qemu/target-ia64/cpu.h b/qemu/target-ia64/cpu.h
index 7349e94..be409c7 100644
--- a/qemu/target-ia64/cpu.h
+++ b/qemu/target-ia64/cpu.h
@@ -73,9 +73,4 @@ CPUState *cpu_ia64_init(void);
 
 #include "cpu-all.h"
 
-/* IA64 has seperate I/D cache, with coherence maintained by DMA controller.
- * So to emulate right behavior that guest OS is assumed, we need to flush
- * I/D cache here.
- */
-void kvm_sync_icache(unsigned long address, int len);
 #endif

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

[PATCH][UPDATE] kvm-userspace: simplify mmio callback

[Christian Ehrhardt]

Subject: [PATCH][UPDATE] kvm-userspace: simplify mmio callback
From: Christian Ehrhardt <ehrhardt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

Merging the read[bwlq]/write[bwlq] callback callback pointers to 
mmio_read/write functions simplifies the callback interface.
On the qemu side it now uses the cpu_physical_memory_rw function.
Additonally this patch merges the RedHat 7.1 mmio workaround that
was spread to two code locations.

Signed-off-by: Christian Ehrhardt <ehrhardt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index 93d7b6b..fd93f44 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -826,44 +826,17 @@ static int handle_mmio(kvm_context_t kvm, struct kvm_run *kvm_run)
 {
 	unsigned long addr = kvm_run->mmio.phys_addr;
 	void *data = kvm_run->mmio.data;
-	int r = -1;
 
-	/* hack: Red Hat 7.1 generates these wierd accesses. */
-	if (addr == 0xa0000 && kvm_run->mmio.len == 3)
+	/* hack: Red Hat 7.1 generates these weird accesses. */
+	if ((addr > 0xa0000-4 && addr <= 0xa0000) && kvm_run->mmio.len == 3)
 	    return 0;
 
-	if (kvm_run->mmio.is_write) {
-		switch (kvm_run->mmio.len) {
-		case 1:
-			r = kvm->callbacks->writeb(kvm->opaque, addr, *(uint8_t *)data);
-			break;
-		case 2:
-			r = kvm->callbacks->writew(kvm->opaque, addr, *(uint16_t *)data);
-			break;
-		case 4:
-			r = kvm->callbacks->writel(kvm->opaque, addr, *(uint32_t *)data);
-			break;
-		case 8:
-			r = kvm->callbacks->writeq(kvm->opaque, addr, *(uint64_t *)data);
-			break;
-		}
-	} else {
-		switch (kvm_run->mmio.len) {
-		case 1:
-			r = kvm->callbacks->readb(kvm->opaque, addr, (uint8_t *)data);
-			break;
-		case 2:
-			r = kvm->callbacks->readw(kvm->opaque, addr, (uint16_t *)data);
-			break;
-		case 4:
-			r = kvm->callbacks->readl(kvm->opaque, addr, (uint32_t *)data);
-			break;
-		case 8:
-			r = kvm->callbacks->readq(kvm->opaque, addr, (uint64_t *)data);
-			break;
-		}
-	}
-	return r;
+	if (kvm_run->mmio.is_write)
+		return kvm->callbacks->mmio_write(kvm->opaque, addr, data,
+					kvm_run->mmio.len);
+	else
+		return kvm->callbacks->mmio_read(kvm->opaque, addr, data,
+					kvm_run->mmio.len);
 }
 
 int handle_io_window(kvm_context_t kvm)
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 110912a..62407f5 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -45,22 +45,12 @@ struct kvm_callbacks {
     int (*outw)(void *opaque, uint16_t addr, uint16_t data);
 	/// For 32bit IO writes from the guest (Usually when executing 'outl')
     int (*outl)(void *opaque, uint16_t addr, uint32_t data);
-	/// For 8bit memory reads from unmapped memory (For MMIO devices)
-    int (*readb)(void *opaque, uint64_t addr, uint8_t *data);
-	/// For 16bit memory reads from unmapped memory (For MMIO devices)
-    int (*readw)(void *opaque, uint64_t addr, uint16_t *data);
-	/// For 32bit memory reads from unmapped memory (For MMIO devices)
-    int (*readl)(void *opaque, uint64_t addr, uint32_t *data);
-	/// For 64bit memory reads from unmapped memory (For MMIO devices)
-    int (*readq)(void *opaque, uint64_t addr, uint64_t *data);
-	/// For 8bit memory writes to unmapped memory (For MMIO devices)
-    int (*writeb)(void *opaque, uint64_t addr, uint8_t data);
-	/// For 16bit memory writes to unmapped memory (For MMIO devices)
-    int (*writew)(void *opaque, uint64_t addr, uint16_t data);
-	/// For 32bit memory writes to unmapped memory (For MMIO devices)
-    int (*writel)(void *opaque, uint64_t addr, uint32_t data);
-	/// For 64bit memory writes to unmapped memory (For MMIO devices)
-    int (*writeq)(void *opaque, uint64_t addr, uint64_t data);
+	/// generic memory reads to unmapped memory (For MMIO devices)
+    int (*mmio_read)(void *opaque, uint64_t addr, uint8_t *data,
+					int len);
+	/// generic memory writes to unmapped memory (For MMIO devices)
+    int (*mmio_write)(void *opaque, uint64_t addr, uint8_t *data,
+					int len);
     int (*debug)(void *opaque, int vcpu);
 	/*!
 	 * \brief Called when the VCPU issues an 'hlt' instruction.
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index cc47ca2..8027ed1 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -477,58 +477,18 @@ static int kvm_outl(void *opaque, uint16_t addr, uint32_t data)
     return 0;
 }
 
-static int kvm_readb(void *opaque, uint64_t addr, uint8_t *data)
+static int kvm_mmio_read(void *opaque, uint64_t addr,
+					uint8_t *data, int len, int is_write)
 {
-    *data = ldub_phys(addr);
-    return 0;
-}
- 
-static int kvm_readw(void *opaque, uint64_t addr, uint16_t *data)
-{
-    *data = lduw_phys(addr);
-    return 0;
-}
-
-static int kvm_readl(void *opaque, uint64_t addr, uint32_t *data)
-{
-    /* hack: Red Hat 7.1 generates some wierd accesses. */
-    if (addr > 0xa0000 - 4 && addr < 0xa0000) {
-	*data = 0;
+	cpu_physical_memory_rw(addr, data, len, 0);
 	return 0;
-    }
-
-    *data = ldl_phys(addr);
-    return 0;
-}
-
-static int kvm_readq(void *opaque, uint64_t addr, uint64_t *data)
-{
-    *data = ldq_phys(addr);
-    return 0;
 }
 
-static int kvm_writeb(void *opaque, uint64_t addr, uint8_t data)
+static int kvm_mmio_write(void *opaque, uint64_t addr,
+					uint8_t *data, int len, int is_write)
 {
-    stb_phys(addr, data);
-    return 0;
-}
-
-static int kvm_writew(void *opaque, uint64_t addr, uint16_t data)
-{
-    stw_phys(addr, data);
-    return 0;
-}
-
-static int kvm_writel(void *opaque, uint64_t addr, uint32_t data)
-{
-    stl_phys(addr, data);
-    return 0;
-}
-
-static int kvm_writeq(void *opaque, uint64_t addr, uint64_t data)
-{
-    stq_phys(addr, data);
-    return 0;
+	cpu_physical_memory_rw(addr, data, len, 1);
+	return 0;
 }
 
 static int kvm_io_window(void *opaque)
@@ -556,14 +516,8 @@ static struct kvm_callbacks qemu_kvm_ops = {
     .outb  = kvm_outb,
     .outw  = kvm_outw,
     .outl  = kvm_outl,
-    .readb = kvm_readb,
-    .readw = kvm_readw,
-    .readl = kvm_readl,
-    .readq = kvm_readq,
-    .writeb = kvm_writeb,
-    .writew = kvm_writew,
-    .writel = kvm_writel,
-    .writeq = kvm_writeq,
+    .mmio_read = kvm_mmio_read,
+    .mmio_write = kvm_mmio_write,
     .halt  = kvm_halt,
     .shutdown = kvm_shutdown,
     .io_window = kvm_io_window,
diff --git a/user/main.c b/user/main.c
index 213b019..4d870fa 100644
--- a/user/main.c
+++ b/user/main.c
@@ -366,7 +366,7 @@ static int test_pre_kvm_run(void *opaque, int vcpu)
 	return 0;
 }
 
-static int test_mem_read(uint64_t addr, void *data, unsigned len)
+static int test_mem_read(void *opaque, uint64_t addr, void *data, unsigned len)
 {
 	if (addr < IORAM_BASE_PHYS || addr + len > IORAM_BASE_PHYS + IORAM_LEN)
 		return 1;
@@ -374,7 +374,7 @@ static int test_mem_read(uint64_t addr, void *data, unsigned len)
 	return 0;
 }
 
-static int test_mem_write(uint64_t addr, void *data, unsigned len)
+static int test_mem_write(void *opaque, uint64_t addr, void *data, unsigned len)
 {
 	if (addr < IORAM_BASE_PHYS || addr + len > IORAM_BASE_PHYS + IORAM_LEN)
 		return 1;
@@ -382,46 +382,6 @@ static int test_mem_write(uint64_t addr, void *data, unsigned len)
 	return 0;
 }
 
-static int test_readb(void *opaque, uint64_t addr, uint8_t *data)
-{
-	return test_mem_read(addr, data, 1);
-}
-
-static int test_readw(void *opaque, uint64_t addr, uint16_t *data)
-{
-	return test_mem_read(addr, data, 2);
-}
-
-static int test_readl(void *opaque, uint64_t addr, uint32_t *data)
-{
-	return test_mem_read(addr, data, 4);
-
-}
-static int test_readq(void *opaque, uint64_t addr, uint64_t *data)
-{
-	return test_mem_read(addr, data, 8);
-}
-
-static int test_writeb(void *opaque, uint64_t addr, uint8_t data)
-{
-	return test_mem_write(addr, &data, 1);
-}
-
-static int test_writew(void *opaque, uint64_t addr, uint16_t data)
-{
-	return test_mem_write(addr, &data, 2);
-}
-
-static int test_writel(void *opaque, uint64_t addr, uint32_t data)
-{
-	return test_mem_write(addr, &data, 4);
-}
-
-static int test_writeq(void *opaque, uint64_t addr, uint64_t data)
-{
-	return test_mem_write(addr, &data, 8);
-}
-
 static struct kvm_callbacks test_callbacks = {
 	.inb         = test_inb,
 	.inw         = test_inw,
@@ -429,14 +389,8 @@ static struct kvm_callbacks test_callbacks = {
 	.outb        = test_outb,
 	.outw        = test_outw,
 	.outl        = test_outl,
-	.readb       = test_readb,
-	.readw       = test_readw,
-	.readl       = test_readl,
-	.readq       = test_readq,
-	.writeb      = test_writeb,
-	.writew      = test_writew,
-	.writel      = test_writel,
-	.writeq      = test_writeq,
+	.mmio_read   = test_mem_read,
+	.mmio_write  = test_mem_write,
 	.debug       = test_debug,
 	.halt        = test_halt,
 	.io_window = test_io_window,

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: [kvm-ppc-devel] [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync

[Avi Kivity]

Christian Ehrhardt wrote:
> Subject: [PATCH][UPDATE] kvm-userspace: sync icache for more architectures
> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
>
> A ia64 patch introduced kvm_sync_icache within a ifdef __ia64__, but the 
> concept of split caches is not bound to ia64. This patch replaces the the 
> call to kvm_synch_icache by the flush_icache_range function
> that is already available in qemu for ia64 and ppc (noop for x86). 
> The call now depends on USE_KVM.
>
>   

Applied, thanks.

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


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [PATCH][UPDATE] kvm-userspace: sync icache for more architectures

[Avi Kivity]

Christian Ehrhardt wrote:
> Subject: [PATCH][UPDATE] kvm-userspace: sync icache for more architectures
> From: Christian Ehrhardt <ehrhardt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
> A ia64 patch introduced kvm_sync_icache within a ifdef __ia64__, but the 
> concept of split caches is not bound to ia64. This patch replaces the the 
> call to kvm_synch_icache by the flush_icache_range function
> that is already available in qemu for ia64 and ppc (noop for x86). 
> The call now depends on USE_KVM.
>
>   

Applied, thanks.

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


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: [kvm-ppc-devel] [kvm-devel] [PATCH][UPDATE] kvm-userspace:

[Avi Kivity]

Christian Ehrhardt wrote:
> Subject: [PATCH][UPDATE] kvm-userspace: simplify mmio callback
> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
>
> Merging the read[bwlq]/write[bwlq] callback callback pointers to 
> mmio_read/write functions simplifies the callback interface.
> On the qemu side it now uses the cpu_physical_memory_rw function.
> Additonally this patch merges the RedHat 7.1 mmio workaround that
> was spread to two code locations.
>   

Applied (after much mulling), thanks.

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


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [PATCH][UPDATE] kvm-userspace: simplify mmio callback

[Avi Kivity]

Christian Ehrhardt wrote:
> Subject: [PATCH][UPDATE] kvm-userspace: simplify mmio callback
> From: Christian Ehrhardt <ehrhardt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
> Merging the read[bwlq]/write[bwlq] callback callback pointers to 
> mmio_read/write functions simplifies the callback interface.
> On the qemu side it now uses the cpu_physical_memory_rw function.
> Additonally this patch merges the RedHat 7.1 mmio workaround that
> was spread to two code locations.
>   

Applied (after much mulling), thanks.

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


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace