On 07/06/2011 03:03 PM, Hannes Reinecke wrote:
uint32_t ldub_phys(target_phys_addr_t addr);
uint32_t lduw_phys(target_phys_addr_t addr);
Hmm? ldub is supposed to read an 'unsigned byte' (uint8_t),
and lduw is supposed to read an 'unsigned word' (uint16_t).
Why does it return an uint32_t?
I d
Am 06.07.2011 um 15:03 schrieb Hannes Reinecke :
> On 07/06/2011 01:34 PM, Alexander Graf wrote:
>>
>>
>>
>>
>> On 06.07.2011, at 12:24, Paolo Bonzini wrote:
>>
diff --git a/exec.c b/exec.c
index 5f2f87e..f281ba4 100644
--- a/exec.c
+++ b/exec.c
@@ -4127,7 +4127,8 @
On 07/06/2011 01:34 PM, Alexander Graf wrote:
On 06.07.2011, at 12:24, Paolo Bonzini wrote:
diff --git a/exec.c b/exec.c
index 5f2f87e..f281ba4 100644
--- a/exec.c
+++ b/exec.c
@@ -4127,7 +4127,8 @@ void cpu_physical_memory_unmap(void *buffer,
target_phys_addr_t len,
}
/* warning: ad
On 06.07.2011, at 12:24, Paolo Bonzini wrote:
>> diff --git a/exec.c b/exec.c
>> index 5f2f87e..f281ba4 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -4127,7 +4127,8 @@ void cpu_physical_memory_unmap(void *buffer,
>> target_phys_addr_t len,
>> }
>>
>> /* warning: addr must be aligned */
>>
diff --git a/exec.c b/exec.c
index 5f2f87e..f281ba4 100644
--- a/exec.c
+++ b/exec.c
@@ -4127,7 +4127,8 @@ void cpu_physical_memory_unmap(void *buffer,
target_phys_addr_t len,
}
/* warning: addr must be aligned */
-uint32_t ldl_phys(target_phys_addr_t addr)
+static inline uint32_t ldl_phys_i
On 06.07.2011, at 00:22, Blue Swirl wrote:
> On Wed, Jul 6, 2011 at 1:13 AM, Alexander Graf wrote:
>>
>> On 06.07.2011, at 00:05, Blue Swirl wrote:
>>
>>> On Wed, Jul 6, 2011 at 12:55 AM, Alexander Graf wrote:
On 05.07.2011, at 23:48, Blue Swirl wrote:
> On Tue, Jul 5, 20
On Wed, Jul 6, 2011 at 12:55 AM, Alexander Graf wrote:
>
> On 05.07.2011, at 23:48, Blue Swirl wrote:
>
>> On Tue, Jul 5, 2011 at 7:28 PM, Alexander Graf wrote:
>>> Device code some times needs to access physical memory and does that
>>> through the ld./st._phys functions. However, these are the
On 05.07.2011, at 23:48, Blue Swirl wrote:
> On Tue, Jul 5, 2011 at 7:28 PM, Alexander Graf wrote:
>> Device code some times needs to access physical memory and does that
>> through the ld./st._phys functions. However, these are the exact same
>> functions that the CPU uses to access memory, whi
On Wed, Jul 6, 2011 at 1:13 AM, Alexander Graf wrote:
>
> On 06.07.2011, at 00:05, Blue Swirl wrote:
>
>> On Wed, Jul 6, 2011 at 12:55 AM, Alexander Graf wrote:
>>>
>>> On 05.07.2011, at 23:48, Blue Swirl wrote:
>>>
On Tue, Jul 5, 2011 at 7:28 PM, Alexander Graf wrote:
> Device code som
On 06.07.2011, at 00:05, Blue Swirl wrote:
> On Wed, Jul 6, 2011 at 12:55 AM, Alexander Graf wrote:
>>
>> On 05.07.2011, at 23:48, Blue Swirl wrote:
>>
>>> On Tue, Jul 5, 2011 at 7:28 PM, Alexander Graf wrote:
Device code some times needs to access physical memory and does that
thro
On Tue, Jul 5, 2011 at 7:28 PM, Alexander Graf wrote:
> Device code some times needs to access physical memory and does that
> through the ld./st._phys functions. However, these are the exact same
> functions that the CPU uses to access memory, which means they will
> be endianness swapped dependi
Device code some times needs to access physical memory and does that
through the ld./st._phys functions. However, these are the exact same
functions that the CPU uses to access memory, which means they will
be endianness swapped depending on the target CPU.
However, devices don't know about the CP
12 matches
Mail list logo
