On Mon, 15 Jun 2026 at 15:56, Michael S. Tsirkin <[email protected]> wrote: > > 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?
Well, that's part of my point about "we need a doc comment": what exactly are we trying to guarantee ? But whatever it is, "hardcoded ifdef that privileges x86" is definitely the wrong answer. -- PMM
