On Mon, 15 Jun 2026 at 11:03, Gavin Shan <[email protected]> wrote: > > All ram device regions were turned to be indirectly accessible by commit > 4a2e242bbb ("memory: Don't use memcpy for ram_device regions"). This leads > to guest hang on attempt to build 'cuda-samples' as reported by Julia. The > guest is started by the following command lines, with GH100 GPU card passed > from the host.
> diff --git a/include/system/memory.h b/include/system/memory.h > index 1417132f6d..5878727d09 100644 > --- a/include/system/memory.h > +++ b/include/system/memory.h > @@ -2897,6 +2897,8 @@ void address_space_register_map_client(AddressSpace > *as, QEMUBH *bh); > void address_space_unregister_map_client(AddressSpace *as, QEMUBH *bh); > > /* Internal functions, part of the implementation of address_space_read. */ > +void qemu_ram_copy(void *dest, const void *src, size_t n); > +void qemu_ram_move(void *dest, const void *src, size_t n); New function prototypes in include headers need documentation comments. In particular for these, it's really important that we clearly say what semantics we are attempting to provide with them, so that (a) when we're reviewing or later updating the implementation we know what we are trying to provide (b) when we're looking at the callsites we know what the function is guaranteeing to us and what it is not, and thus whether it's OK to use it or we need something els. > +#if defined(__i386__) || defined(__x86_64__) > +#define HOST_UNALIGNED_MMIO_OK 1 > +#else > +#define HOST_UNALIGNED_MMIO_OK 0 > +#endif We need to do something better than this. We can't just say "oh, we trust that on x86 this works": it is neither actually true that the compiler guarantees it even on x86, nor is it the case that only x86 can do unaligned accesses to normal RAM. thanks -- PMM
