On Sun, Dec 15, 2019 at 03:27:12PM +0000, Peter Maydell wrote: > On Sun, 15 Dec 2019 at 09:51, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > On Sat, Dec 14, 2019 at 04:28:08PM +0000, Peter Maydell wrote: > > > (It doesn't actually assert that it doesn't > > > overlap because we have some legacy uses, notably > > > in the x86 PC machines, which do overlap without using > > > the right function, which we've never tried to tidy up.) > > > > It's not exactly legacy uses. > > > > To be more exact, the way the non overlap versions > > are *used* is to mean "I don't care what happens when they overlap" > > as opposed to "will never overlap". > > Almost all of the use of the non-overlap versions is > for "these are never going to overlap" -- devices or ram at > fixed addresses in the address space that can't > ever be mapped over by anything else. If you want > "can overlap but I don't care which one wins" then > that would be more clearly expressed by using the _overlap() > version but just giving everything that can overlap there > the same priority. Problem is device doesn't always know whether something can overlap it. Imagine device A at a fixed address. Guest can program device B to overlap the fixed address. How is device A supposed to know this can happen? > > There are lots of regions where guest can make things overlapping > > but doesn't, e.g. PCI BARs can be programmed to overlap > > almost anything. > > > > What happens on real hardware if you then access one of > > the BARs is undefined, but programming itself is harmless. > > That's why we can't assert. > > Yeah, good point, for the special case where it's the > guest that's determining the addresses where something's > mapped we might want to allow the behaviour to fall out > of the implementation. (You could instead specify set of > priorities that makes the undefined-behaviour something > specific, rather than just an emergent property of > the implementation QEMU happens to have, but it seems > a bit hard to justify.) > > thanks > -- PMM
