On Mon, Jun 15, 2026 at 11:57:09AM +0100, Peter Maydell wrote: > 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
sorry guarantee what? > even > on x86, nor is it the case that only x86 can do unaligned > accesses to normal RAM. > > thanks > -- PMM
