From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzCl5-00038O-8Z for qemu-devel@nongnu.org; Thu, 01 Sep 2011 15:17:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzCl3-0003uz-M7 for qemu-devel@nongnu.org; Thu, 01 Sep 2011 15:17:03 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:56657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzCl3-0003um-EB for qemu-devel@nongnu.org; Thu, 01 Sep 2011 15:17:01 -0400 Received: by gwb19 with SMTP id 19so1277895gwb.4 for ; Thu, 01 Sep 2011 12:17:00 -0700 (PDT) From: "Adnan Khaleel" Message-ID: <20110901191655.5b42e714@shadowfax.no-ip.com> Date: Thu, 01 Sep 2011 14:16:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------2da77d2cbced2b9d1e5bfdc158618372" 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: qemu-devel@nongnu.org Cc: blauwirbel@gmail.com This is a multi-part message in MIME format. -------------2da77d2cbced2b9d1e5bfdc158618372 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had asked this question a year ago and I managed to have a temporary w= ork around for doing a single 64bit read/write operations but now I'm lo= oking for a more complete solution. Is there anyway we can prevent Qemu breaking up 64,128 and 256bit XMM or= YMM instructions into smaller chunks and have them issue as a single tr= ansaction of the original width=3F This is not an issue for reading/writ= ing to the processor's memory but for an I/O device attached over PCI. O= ne hack is that I could accumulate the writes as they're happening but I= have no way of knowing if the writes are from the same instruction. Thanks AK Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit me =5F=5F=5F=5F=5F =20 =20 From: Blue Swirl =20 Subject: Re: [Qemu-devel] Single 64bit memory transaction inst= ead of two 32bit memory transaction. =20 Date: Tue, 9 Nov 2010 17:57:28 +0000 > Legacy. Patches have been submitted to add 64 bit IO handlers. But > = there have been other discussions to change the whole I/O interface.=20 > On Mon, Nov 8, 2010 at 11:27 PM, Adnan Khaleel wrote:= >> In the file exec.c: >> The memory Write/Read functions are declared as an array of 4 entri= es where the index values of 0,1,2 correspond to 8,16 and 32bit write = and read functions respectively. >> CPUWriteMemoryFunc *io=5Fmem=5Fwrite[IO=5FMEM=5FNB=5FENTRIES][4]; >> CPUReadMemoryFunc *io=5Fmem=5Fread[IO=5FMEM=5FNB=5FENTRIES][4]; >> Is there any reason why we can't extend this to include 64bit write= s and read by increasing the array size=3F This is because 64bit reads= are currently handled as two separate 32bit reads for eg: sommu=5Ftem= plate.h >> static inline DATA=5FTYPE glue(io=5Fread, SUFFIX)(target=5Fphys=5Fadd= r=5Ft physaddr, >> target=5Fulong addr, >> void *retaddr) >> { >> : >> res =3D io=5Fmem=5Fread[index][2](io=5Fmem=5Fopaque[index], physad= dr); >> res |=3D (uint64=5Ft)io=5Fmem=5Fread[index][2](io=5Fmem=5Fopaque[i= ndex], physaddr + 4) << 32; >>: >> return res; >>} >> I'm sure this is happening in other places as well. Is there a reas= on for this or could we arbitrarily increase this (within limits >> of= course)=3F >> Thanks >> AK -------------2da77d2cbced2b9d1e5bfdc158618372 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had asked this question a year ago and I managed to have a temporary w= ork around for doing a single 64bit read/write operations but now I'm lo= oking for a more complete solution.

Is there anyway we can preven= t Qemu breaking up 64,128 and 256bit XMM or YMM instructions into smalle= r chunks and have them issue as a single transaction of the original wid= th=3F This is not an issue for reading/writing to the processor's memory= but for an I/O device attached over PCI. One hack is that I could accum= ulate the writes as they're happening but I have no way of knowing if th= e writes are from the same instruction.

Thanks

AK

<= h2 style=3D"font-family: Courier; font-weight: bold;">R= e: [Qemu-devel] Single 64bit memory transaction instead of two 32bit=09m= e
From: Blue Swirl
Subject: Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit=09= memory transaction.
Date: Tue, 9 Nov 2010 17:57:28 +0000

=
> Legacy. Patches have been submitted to add 64 bit IO handlers. But
> there have been other discussions to change the whole I/O interface=
. 

> On Mon, Nov 8, 2010 at 11:27 PM, Adnan Khaleel <addr=
ess@hidden> wrote:
>> In the file exec.c:

>> =
The memory Write/Read functions are declared=20
as an array of 4 entries where the index values of 0,1,2 correspond to=
=20
8,16 and 32bit write and read functions respectively.

>> CP=
UWriteMemoryFunc *io=5Fmem=5Fwrite[IO=5FMEM=5FNB=5FENTRIES][4];
>&=
gt; CPUReadMemoryFunc *io=5Fmem=5Fread[IO=5FMEM=5FNB=5FENTRIES][4];
<=
br>>> Is
 there any reason why we can't extend this to include 64bit writes and=
=20
read by increasing the array size=3F This is because 64bit reads are=20
currently handled as two separate 32bit reads for eg: sommu=5Ftemplate.h=


>> static inline DATA=5FTYPE glue(io=5Fread, SUFFIX)(targe=
t=5Fphys=5Faddr=5Ft physaddr,
>>      =
            =
            =
            =
     target=5Fulong addr,
>>   &n=
bsp;           &n=
bsp;           &n=
bsp;           &n=
bsp;       void *retaddr)
>> {>> :
>>    res =3D io=5Fmem=5Fread[index]=
[2](io=5Fmem=5Fopaque[index], physaddr);
>>    r=
es |=3D (uint64=5Ft)io=5Fmem=5Fread[index][2](io=5Fmem=5Fopaque[index], =
physaddr + 4) << 32;
>>:
>>    re=
turn res;
>>}

>> I'm
 sure this is happening in other places as well. Is there a reason for=
=20
this or could we arbitrarily increase this (within limits >> ofcou=
rse)=3F

>> Thanks

>> AK

-------------2da77d2cbced2b9d1e5bfdc158618372--