RE: [Xen-devel] Custom Hardware Acceleration

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jad Naous
> Sent: 26 January 2006 08:52
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Custom Hardware Acceleration
> 
> Hi all,
> I am exploring the possibility of designing a custom hardware 
> acceleration solution using an ASIC or an FPGA to accelerate 
> some part of Xen. Basically, I am looking for some part of 
> the code that could be built in hardware to make it faster. 
> Does anybody know where I could get some statistics on the 
> code, such as the most called functions, the most 
> parallelizable functions, etc... If you could think of 
> something that would be useful in HW I would be very 
> interested to know.
> Thanks,
> Jad.

Xen's "load" on the system is going to be mainly in performing CPU tasks
for something that in the non-Xen case would be handled by the ordinary
hardware/microprocessor itself, such a s trapping memory mapped IO
acccesses, IOIO accesses or page-table translation (using the "Shadow
page-table" scheme). 

Unfortunately, unless your ASIC becomes part of the CPU itself, I think
it's unlikely that you'd be able to speed things up noticably... 

The speed of, for example, block device accesses, is very much dependant
on the speed of transfer to/from the block-device, and very little on
the speed of the operations added by Xen (although admittedly, adding a
layer of software between the requesting software and the hardware
servicing the request will ALWAYS add some delay, and you can only ADD
delay, never take it away...)

Unless of course, you want to build a very complex device, such as a
multi-guest capable graghics card (one that can draw to multiple display
surfaces at any given time and switch between these based on some
software/hardware switching mechanism). A company called Level5 has a
network card that supports multiple guests... 

I'd be very interested in hearing a differign view, of course. 

[Note that I work for AMD, but I'm a Software engineer, so I don't
necessarily understand all of the Hardware Implications...]

--
Mats


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel