From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzypT-0005KA-M6 for qemu-devel@nongnu.org; Sat, 03 Sep 2011 18:36:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzypS-0000mN-C2 for qemu-devel@nongnu.org; Sat, 03 Sep 2011 18:36:47 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:33772) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzypS-0000mD-9P for qemu-devel@nongnu.org; Sat, 03 Sep 2011 18:36:46 -0400 Received: by gwb19 with SMTP id 19so2599651gwb.4 for ; Sat, 03 Sep 2011 15:36:44 -0700 (PDT) From: "Adnan Khaleel" In-Reply-To: 4E61889A.9080707@twiddle.net Message-ID: <20110903223642.356831a4@shadowfax.no-ip.com> Date: Sat, 03 Sep 2011 17:36:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------a516a50c4361dea57933856a7c03d0f6" Subject: Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction Reply-To: adnan@khaleel.us List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org This is a multi-part message in MIME format. -------------a516a50c4361dea57933856a7c03d0f6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a patch for the new MemoryRegion API=3F=20 At least for now, I need to be able to issue a single 64, 128 or 256bit = transaction to a particular IO device. Is there a way I can do this now = as a temp solution=3F I don't mind coalescing the bytes as they are issu= ed by Qemu but I have no way to know that they're from the same instruct= ion. Any pointers=3F Thanks, AK =5F=5F=5F=5F=5F =20 From: Richard Henderson [mailto:rth@twiddle.net] To: adnan@khaleel.us Cc: qemu-devel@nongnu.org, blauwirbel@gmail.com Sent: Fri, 02 Sep 2011 20:53:30 -0500 Subject: Re: [Qemu-devel] Single 64bit memory transaction instead of two= 32bit memory transaction On 09/02/2011 12:46 AM, Adnan Khaleel wrote: > Is there anyway we can prevent Qemu breaking up 64,128 and 256bit XM= M or YMM instructions into smaller chunks and have them issue as a singl= e transaction of the original width=3F =20 Not yet. The new MemoryRegion API will allow this, but we need to con= vert all=20 the devices first, then rip out the old API. =20 It's a work in progress... =20 =20 r~ =20 -------------a516a50c4361dea57933856a7c03d0f6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a patch for the new MemoryRegion API=3F 

At least for now, I need to be able to issue a single 64, 128 or 256bi= t transaction to a particular IO device. Is there a way I can do this no= w as a temp solution=3F I don't mind coalescing the bytes as they a= re issued by Qemu but I have no way to know that they're from the same i= nstruction. Any pointers=3F

Thanks,
<= br>
AK
F= rom: Richard Henderson [mailto:rth@twiddle.net]
To: adnan@= khaleel.us
Cc: qemu-devel@nongnu.org, blauwirbel@gmail.com
= Sent: Fri, 02 Sep 2011 20:53:30 -0500
Subject: Re: [Qem= u-devel] Single 64bit memory transaction instead of two 32bit memory tra= nsaction

On 09/02/2011 12:46 AM, Adnan Khaleel wrote:
> Is there anyway we can prevent Qemu breaking up 64,128 and 256bit X= MM or YMM instructions into smaller chunks and have them issue as a sing= le transaction of the original width=3F

Not yet. The new MemoryRegion API will allow this, but we need to conve= rt all
the devices first, then rip out the old API.

It's a work in progress...


r~
-------------a516a50c4361dea57933856a7c03d0f6--