[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Support for SSE/MMX instructions.


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Fri, 21 Apr 2006 15:26:26 +0200
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 21 Apr 2006 06:27:04 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZkk5cKKmw9RONtRRyBPBW4ZabMawAshI4A
  • Thread-topic: [Xen-devel] Support for SSE/MMX instructions.

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Keir Fraser
> Sent: 20 April 2006 17:00
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Support for SSE/MMX instructions.
> 
> 
> On 20 Apr 2006, at 16:37, Petersson, Mats wrote:
> 
> > 1. Is anyone else working on anything like this (expanding 
> the valid 
> > instructions that can access memory-mapped IO to include 
> either SSE or 
> > MMX instructions?)
> 
> I don't think so. Best would be to move all HVM I/O emulation 
> to the common Xen emulator (x86_emulate.c) and add the needed 
> emulation there. 

I've looked a little bit at doing that - and it would probably make
sense to merge x86_emulate and the hvm handle_mmio() code, but there are
some stuff done in the handle_mmio() code that isn't done in
x86_emulate. I'll look a little further to see if I can make something
out of it [it's clearly not very clever to have two pieces of code that
decodes/emulates instructions!]

> Either way I expect that we will only need to emulate a very 
> few SSE instructions (I expect this case is the result of an 
> optimised memset()?).

I would expect to only see very few operations:
MOVQ, MOVDQ[AU], MOVNTQ, MOVNTDQ[AU]. 

And, yes in conjunction with memset/memcpy and closely related/in-lined
or specialized versions [I know 3DLabs use combinations of regular and
SSE instructions to copy data in the OpenGL library for example, and
although that gets written to regular memory, not MMIO, I can certainly
imagine that someone might use the same type of mix for other types of
operations]. For MMIO operations, I would say that the majority would
probably be copying data to or from someplace to an memory mapped IO
location. I've very rarely seen code do memset on memory-mapped IO
locations (but I guess a "clear-screen" in the form of memset((void
*)0xb8000, 0, 4000); would be such a case...)


> 
> > 2. Does anyone have a hint on how we best get the MMX and SSE 
> > registers so that they can be accessed in hvm/platform.c?
> 
> Call unlazy_fpu(current) and then read/write the appropriate fields in
> current->arch.guest_context.fpu_ctxt.

That's what I thought - but I wanted to make sure... ;-)

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


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.