On Mon, 25 May 2026, Peter Maydell wrote:
On Mon, 25 May 2026 at 16:47, BALATON Zoltan <[email protected]> wrote:
Make memory_region_set_ops() function public. In some cases such as
when devices have configurable endianness or different behaviour based
on settings it is necessary to change the ops callback after the
memory region is created. Export memory_region_set_ops() function for
this.
If some other CPU is in the middle of using the old MemoryRegionOps
when the device swaps them out under its feet, what happens?
In my limited test with PPC and ati-vga this seems to work and the switch
would happen in device register write so nothing else is expected to run
accessing the device at the same time at that point. I can't tell for all
possible cases but that would then be a problem in the caller not in this
function. Callers are expected to call it when appropriate which I could
mention in the doc comment if needed.
You could also remove the old MR from its container and add a different
one with the different behaviour when the guest changes the config,
or have both of them in the container and toggle which is visible
with memory_region_set_enabled(). That might potentially be more
awkward but it would avoid having to look into the memory region
API internals.
That could also work if I had a container but it's switching the
endianness of a PCI BAR which is registered with pci_register_bar() so
it's easiest to switch the ops on the region than hacking around it using
two more otherwise unneeded memory regions as I also can't swap PCI BARs
so it would need a container aditionally to two regions using the same
callbacks just with different endianness. Allowing setting the ops of a
single region seems simpler.
Regards,
BALATON Zoltan
