Message ID | 20231116163633.276671-1-venture@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2] system/memory: use ldn_he_p/stn_he_p | expand |
On 16/11/23 17:36, Patrick Venture wrote: > Using direct pointer dereferencing can allow for unaligned accesses, > which was seen during execution with sanitizers enabled. > > Reviewed-by: Chris Rauer <crauer@google.com> > Reviewed-by: Peter Foley <pefoley@google.com> > Signed-off-by: Patrick Venture <venture@google.com> > Cc: qemu-stable@nongnu.org > --- > v2: changed commit mesage to be more accurate and switched from using > memcpy to using the endian appropriate assignment load and store. > --- > system/memory.c | 32 ++------------------------------ > 1 file changed, 2 insertions(+), 30 deletions(-) Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
On 16.11.23 17:36, Patrick Venture wrote: > Using direct pointer dereferencing can allow for unaligned accesses, > which was seen during execution with sanitizers enabled. > > Reviewed-by: Chris Rauer <crauer@google.com> > Reviewed-by: Peter Foley <pefoley@google.com> > Signed-off-by: Patrick Venture <venture@google.com> > Cc: qemu-stable@nongnu.org Reviewed-by: David Hildenbrand <david@redhat.com>
On Fri, Nov 17, 2023 at 12:43 AM David Hildenbrand <david@redhat.com> wrote: > On 16.11.23 17:36, Patrick Venture wrote: > > Using direct pointer dereferencing can allow for unaligned accesses, > > which was seen during execution with sanitizers enabled. > > > > Reviewed-by: Chris Rauer <crauer@google.com> > > Reviewed-by: Peter Foley <pefoley@google.com> > > Signed-off-by: Patrick Venture <venture@google.com> > > Cc: qemu-stable@nongnu.org > > > > Reviewed-by: David Hildenbrand <david@redhat.com> > > -- > Cheers, > > David / dhildenb > Friendly ping? Is this going to be applied or do I need to add another CC or? I do think it should go into stable.
Hi Patrick, On 3/12/23 16:42, Patrick Venture wrote: > Friendly ping? Is this going to be applied or do I need to add another > CC or? I do think it should go into stable. I'll send a PR with this patch included. Regards, Phil.
On Mon, Dec 4, 2023 at 3:24 AM Philippe Mathieu-Daudé <philmd@linaro.org> wrote: > Hi Patrick, > > On 3/12/23 16:42, Patrick Venture wrote: > > > Friendly ping? Is this going to be applied or do I need to add another > > CC or? I do think it should go into stable. > > I'll send a PR with this patch included. > Thanks! > > Regards, > > Phil. >
diff --git a/system/memory.c b/system/memory.c index 304fa843ea..affc7ea83c 100644 --- a/system/memory.c +++ b/system/memory.c @@ -1339,22 +1339,7 @@ static uint64_t memory_region_ram_device_read(void *opaque, hwaddr addr, unsigned size) { MemoryRegion *mr = opaque; - uint64_t data = (uint64_t)~0; - - switch (size) { - case 1: - data = *(uint8_t *)(mr->ram_block->host + addr); - break; - case 2: - data = *(uint16_t *)(mr->ram_block->host + addr); - break; - case 4: - data = *(uint32_t *)(mr->ram_block->host + addr); - break; - case 8: - data = *(uint64_t *)(mr->ram_block->host + addr); - break; - } + uint64_t data = ldn_he_p(mr->ram_block->host + addr, size); trace_memory_region_ram_device_read(get_cpu_index(), mr, addr, data, size); @@ -1368,20 +1353,7 @@ static void memory_region_ram_device_write(void *opaque, hwaddr addr, trace_memory_region_ram_device_write(get_cpu_index(), mr, addr, data, size); - switch (size) { - case 1: - *(uint8_t *)(mr->ram_block->host + addr) = (uint8_t)data; - break; - case 2: - *(uint16_t *)(mr->ram_block->host + addr) = (uint16_t)data; - break; - case 4: - *(uint32_t *)(mr->ram_block->host + addr) = (uint32_t)data; - break; - case 8: - *(uint64_t *)(mr->ram_block->host + addr) = data; - break; - } + stn_he_p(mr->ram_block->host + addr, size, data); } static const MemoryRegionOps ram_device_mem_ops = {