[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/8] Simplify memory_region_add_subregion_overlap(..., priori
|
From: |
Michael S. Tsirkin |
|
Subject: |
Re: [PATCH 0/8] Simplify memory_region_add_subregion_overlap(..., priority=0) |
|
Date: |
Mon, 16 Dec 2019 06:39:56 -0500 |
On Sun, Dec 15, 2019 at 03:27:12PM +0000, Peter Maydell wrote:
> On Sun, 15 Dec 2019 at 09:51, Michael S. Tsirkin <address@hidden> 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
- [PATCH 6/8] hw/vfio/pci: Use memory_region_add_subregion() when priority is 0, (continued)
- [PATCH 6/8] hw/vfio/pci: Use memory_region_add_subregion() when priority is 0, Philippe Mathieu-Daudé, 2019/12/14
- [PATCH 5/8] hw/mips/boston: Use memory_region_add_subregion() when priority is 0, Philippe Mathieu-Daudé, 2019/12/14
- [PATCH 7/8] target/i386: Use memory_region_add_subregion() when priority is 0, Philippe Mathieu-Daudé, 2019/12/14
- [PATCH 4/8] hw/i386/intel_iommu: Use memory_region_add_subregion when priority is 0, Philippe Mathieu-Daudé, 2019/12/14
- Re: [PATCH 0/8] Simplify memory_region_add_subregion_overlap(..., priority=0), Peter Maydell, 2019/12/14
- Re: [PATCH 0/8] Simplify memory_region_add_subregion_overlap(..., priority=0), Michael S. Tsirkin, 2019/12/15