Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction

Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction

[Adnan Khaleel]

[-- Attachment #1: Type: text/plain, Size: 2295 bytes --]

I had asked this question a year ago and I managed to have a temporary work around for doing a single 64bit read/write operations but now I'm looking 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 transaction of the original width? 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 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
    _____  

      

     From:      Blue Swirl          
     Subject:      Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit 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 <address@hidden> wrote:>> In the file exec.c:

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

>> CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][4];
>> CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];

>> Is   there any reason why we can't extend this to include 64bit writes and   read by increasing the array size? This is because 64bit reads are   currently handled as two separate 32bit reads for eg: sommu_template.h

>> static inline DATA_TYPE glue(io_read, SUFFIX)(target_phys_addr_t physaddr,
>>                                               target_ulong addr,
>>                                               void *retaddr)
>> {
>> :
>>    res = io_mem_read[index][2](io_mem_opaque[index], physaddr);
>>    res |= (uint64_t)io_mem_read[index][2](io_mem_opaque[index], physaddr + 4) << 32;
>>:
>>    return res;
>>}

>> I'm   sure this is happening in other places as well. Is there a reason for   this or could we arbitrarily increase this (within limits >> ofcourse)?

>> Thanks

>> AK

[-- Attachment #2: Type: text/html, Size: 4035 bytes --]

Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction

[Richard Henderson]

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~

Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction

[Adnan Khaleel]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

Is there a patch for the new MemoryRegion API? 


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? I don't mind coalescing the bytes as they are issued by Qemu but I have no way to know that they're from the same instruction. Any pointers?


Thanks,


AK
  _____  

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

[-- Attachment #2: Type: text/html, Size: 1592 bytes --]

Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction.

[Blue Swirl]

On Mon, Nov 8, 2010 at 11:27 PM, Adnan Khaleel <adnan@khaleel.us> wrote:
> In the file exec.c:
>
> The memory Write/Read functions are declared as an array of 4 entries where
> the index values of 0,1,2 correspond to 8,16 and 32bit write and read
> functions respectively.
>
> CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][4];
> CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];
>
> Is there any reason why we can't extend this to include 64bit writes and
> read by increasing the array size? This is because 64bit reads are currently
> handled as two separate 32bit reads for eg: sommu_template.h
>
> static inline DATA_TYPE glue(io_read, SUFFIX)(target_phys_addr_t physaddr,
>                                               target_ulong addr,
>                                               void *retaddr)
> {
> :
>     res = io_mem_read[index][2](io_mem_opaque[index], physaddr);
>     res |= (uint64_t)io_mem_read[index][2](io_mem_opaque[index], physaddr +
> 4) << 32;
> :
>     return res;
> }
>
> I'm sure this is happening in other places as well. Is there a reason for
> this or could we arbitrarily increase this (within limits ofcourse)?

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

[Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction.

[Adnan Khaleel]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

In the file exec.c:

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

CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][4];
CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];

Is there any reason why we can't extend this to include 64bit writes and read by increasing the array size? This is because 64bit reads are currently handled as two separate 32bit reads for eg: sommu_template.h

static inline DATA_TYPE glue(io_read, SUFFIX)(target_phys_addr_t physaddr,
                                              target_ulong addr,
                                              void *retaddr)
{
:
    res = io_mem_read[index][2](io_mem_opaque[index], physaddr);
    res |= (uint64_t)io_mem_read[index][2](io_mem_opaque[index], physaddr + 4) << 32;
:
    return res;
}

I'm sure this is happening in other places as well. Is there a reason for this or could we arbitrarily increase this (within limits ofcourse)?

Thanks

AK

[-- Attachment #2: Type: text/html, Size: 1906 bytes --]