Blue Swirl · 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--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:57077)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1QzfQV-0007ou-Cm
	for qemu-devel@nongnu.org; Fri, 02 Sep 2011 21:53:44 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from ) id 1QzfQU-0004UQ-IV
	for qemu-devel@nongnu.org; Fri, 02 Sep 2011 21:53:43 -0400
Received: from mail-gw0-f45.google.com ([74.125.83.45]:41939)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1QzfQU-0004UM-EJ
	for qemu-devel@nongnu.org; Fri, 02 Sep 2011 21:53:42 -0400
Received: by gwb19 with SMTP id 19so2308376gwb.4
	for ; Fri, 02 Sep 2011 18:53:41 -0700 (PDT)
Sender: Richard Henderson 
Message-ID: <4E61889A.9080707@twiddle.net>
Date: Sat, 03 Sep 2011 07:23:30 +0530
From: Richard Henderson 
MIME-Version: 1.0
References: <20110901191655.5b42e714@shadowfax.no-ip.com>
In-Reply-To: <20110901191655.5b42e714@shadowfax.no-ip.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Single 64bit memory transaction instead of two
 32bit memory transaction
List-Id: 
List-Unsubscribe: ,

List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,

To: adnan@khaleel.us
Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org

On 09/02/2011 12:46 AM, Adnan Khaleel wrote:
> 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 transaction of the original width?

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

It's a work in progress...

r~

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--

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