On Mon, 16 Dec 2019 at 11:40, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > 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? That's why (the original intention was) only one of the regions needs to be marked 'overlap OK', not both. thanks -- PMM
