Re: [kvm-devel] [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

2007-10-29 Thread Anthony Liguori
Hollis Blanchard wrote:
 On Sun, 2007-10-28 at 22:50 -0500, Anthony Liguori wrote:
   
 You could certainly get even more clever and have the arch backend 
 register the appropriate tables based on the as type but that's merely
 an implementation detail.  The key observation, that I believe is
 correct, is that all architectures have one or more IO address
 spaces that have at max a 64-bit address space and support at max
 64-bit input/output operations.  Once that assumption is made, almost
 all IO code becomes common.
 

 Just FYI, some PowerPC have load/store quad, which are 128-bit memory
 accesses.

Can you do MMIO with these instructions though?  I'm not really sure 
what would happen on x86 if you did MMIO with a 128-bit instruction.

Regards,

Anthony Liguori

  For that matter, I suppose one could do IO loads into Altivec
 registers (which are also 128 bits), though that sounds like an extreme
 case. I wonder if the same is true for x86 vector registers.

 Also, can't x86 rep instructions go beyond 64 bits? I guess that must
 be handled in the arch-specific caller of io_write(), which would call
 it multiple times.

   


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


Re: [kvm-devel] [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

2007-10-29 Thread Avi Kivity
Hollis Blanchard wrote:
 Also, can't x86 rep instructions go beyond 64 bits? I guess that must
 be handled in the arch-specific caller of io_write(), which would call
 it multiple times.
   
'rep' has special support in the ABI (it's N accesses of M bits, not an 
NxM bit access).

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


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


Re: [kvm-devel] [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

2007-10-28 Thread Hollis Blanchard
On Sun, 2007-10-28 at 21:11 -0500, Anthony Liguori wrote:
 
 int (*io_write)(void *opaque, int as, uint64_t addr, uint64_t data,
 int size);
 
 Where as is a #define representing the address space (on x86, there is
 the PIO and MMIO address spaces, on PPC, there is just MMIO).

So the implementation would look something like this:

int io_write(void *opaque, int as, uint64_t addr, uint64_t data, int
size) {
io_handler_t cb;

switch (as) {
case MMIO:
cb = io_table_lookup(mmio_table, ...)
break;
#ifdef HAS_PIO
case PIO:
cb = io_table_lookup(pio_table, ...)
break;
#endif
#ifdef HAS_DCR
case DCR:
cb = io_table_lookup(dcr_table, ...)
break;
#endif
default:
cb = NULL;
}

if (cb)
return cb(...);

printk(error);
return -EINVAL;
}

Sounds fine to me.

-- 
Hollis Blanchard
IBM Linux Technology Center


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


Re: [kvm-devel] [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

2007-10-28 Thread Anthony Liguori
Hollis Blanchard wrote:
 On Sun, 2007-10-28 at 21:11 -0500, Anthony Liguori wrote:
   
 int (*io_write)(void *opaque, int as, uint64_t addr, uint64_t data,
 int size);

 Where as is a #define representing the address space (on x86, there is
 the PIO and MMIO address spaces, on PPC, there is just MMIO).
 

 So the implementation would look something like this:

 int io_write(void *opaque, int as, uint64_t addr, uint64_t data, int
 size) {
 io_handler_t cb;
 
 switch (as) {
 case MMIO:
 cb = io_table_lookup(mmio_table, ...)
 break;
 #ifdef HAS_PIO
 case PIO:
 cb = io_table_lookup(pio_table, ...)
 break;
 #endif
 #ifdef HAS_DCR
 case DCR:
 cb = io_table_lookup(dcr_table, ...)
 break;
 #endif
 default:
 cb = NULL;
 }
 
 if (cb)
 return cb(...);
 
 printk(error);
 return -EINVAL;
 }

 Sounds fine to me.
   

You could certainly get even more clever and have the arch backend 
register the appropriate tables based on the as type but that's merely 
an implementation detail.  The key observation, that I believe is 
correct, is that all architectures have one or more IO address spaces 
that have at max a 64-bit address space and support at max 64-bit 
input/output operations.  Once that assumption is made, almost all IO 
code becomes common.

Regards,

Anthony Liguori



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


Re: [kvm-devel] [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

2007-10-28 Thread Hollis Blanchard
On Sun, 2007-10-28 at 22:50 -0500, Anthony Liguori wrote:
 
 You could certainly get even more clever and have the arch backend 
 register the appropriate tables based on the as type but that's merely
 an implementation detail.  The key observation, that I believe is
 correct, is that all architectures have one or more IO address
 spaces that have at max a 64-bit address space and support at max
 64-bit input/output operations.  Once that assumption is made, almost
 all IO code becomes common.

Just FYI, some PowerPC have load/store quad, which are 128-bit memory
accesses. For that matter, I suppose one could do IO loads into Altivec
registers (which are also 128 bits), though that sounds like an extreme
case. I wonder if the same is true for x86 vector registers.

Also, can't x86 rep instructions go beyond 64 bits? I guess that must
be handled in the arch-specific caller of io_write(), which would call
it multiple times.

-- 
Hollis Blanchard
IBM Linux Technology Center


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