On Wed, Dec 11, 2024 at 09:56:21AM +0000, Peter Maydell wrote: > On Fri, 6 Dec 2024 at 16:43, Peter Xu <pet...@redhat.com> wrote: > > I assume it's about xhci_cap_ops then. If you agree we can also mention > > xhci_cap_ops when dscribing it, so readers can easily reference the MR > > attributes from the code alongside with understanding the use case. > > > > Does it mean that it could also work if xhci_cap_ops.impl.min_access_size > > can be changed to 2 (together with additional xhci_cap_read/write support)? > > > > Note that I'm not saying it must do so even if it would work for xHCI, but > > if the memory API change is only for one device, then it can still be > > discussed about which option would be better on changing the device or the > > core. > > I think the memory system core has been broken in this area > for a long time -- it purports to support impls which only > do a subset of what the valid operations are, but it actually > does buggy and wrong things in some cases. So far > we have effectively worked around it by avoiding defining > MemoryRegionOps that try to use the buggy areas, but I > think it's much better to fix the code so it really does > what it's theoretically intended to do.
Thanks, Peter. I assume it means there're a lot of devices that can use this model. Then it makes perfect sense to do it in memory core. Though I do have some confusion on why we needed impl.unaligned at all. I see that Tomoyuki raised similar question, even if not exactly the same one. I'll try to continue the discussion there. -- Peter Xu
