Re: [Qemu-devel] [RFC] Memory API

[Gleb Natapov]

On Thu, May 19, 2011 at 01:57:15PM +0200, Jan Kiszka wrote:
> On 2011-05-19 13:54, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 02:44:29PM +0300, Avi Kivity wrote:
> >> On 05/19/2011 12:14 PM, Gleb Natapov wrote:
> >>> On Thu, May 19, 2011 at 12:10:38PM +0300, Avi Kivity wrote:
> >>>>  On 05/19/2011 12:08 PM, Gleb Natapov wrote:
> >>>>  >On Wed, May 18, 2011 at 06:42:14PM +0300, Avi Kivity wrote:
> >>>>  >>   On 05/18/2011 06:36 PM, Jan Kiszka wrote:
> >>>>  >>   >>
> >>>>  >>   >>    We need to head for the more hardware-like approach.  What 
> >>>> happens when
> >>>>  >>   >>    you program overlapping BARs?  I imagine the result is
> >>>>  >>   >>    implementation-defined, but ends up with one region decoded 
> >>>> in
> >>>>  >>   >>    preference to the other.  There is simply no way to reject an
> >>>>  >>   >>    overlapping mapping.
> >>>>  >>   >
> >>>>  >>   >But there is also now simple way to allow them. At least not 
> >>>> without
> >>>>  >>   >exposing control about their ordering AND allowing to hook up 
> >>>> managing
> >>>>  >>   >code (e.g. of the PCI bridge or the chipset) that controls 
> >>>> registrations.
> >>>>  >>
> >>>>  >>   What about memory_region_add_subregion(..., int priority) as I
> >>>>  >>   suggested in another message?
> >>>>  >Haven't saw another message yet, but how caller knows about priority?
> >>>>
> >>>>  The caller is emulating some hub or router and should decide on
> >>>>  priority like real hardware.
> >>>>
> >>>>  For example, piix gives higher priority to the vga window over RAM.
> >>>>
> >>> Hmm, but if a caller of the memory_region_add_subregion() function is a
> >>> device itself how does it know about chipset priorities. All it wants to
> >>> tell to the system is that it is ready to handle mmio access in this phys
> >>> range, but chipset may decide to forward those accesses elsewhere.
> >>
> >> In this case the device would call a chipset function, passing the
> >> memory region as a parameter, and the chipset would call
> >> m_r_add_subregion().
> > But then chipset can resolve all overlapping by itself and register only
> > regions that are actually accessible by a guest software. Also there are
> > devices that on some architectures are accessed through a chipset and on
> > other they resides directly on a system bus. If they will need to call
> > different memory registration api depending on how they are instantiated
> > the code can become messy.
> 
> Devices shall register their regions with the bus. Every device is on
> some bus, so that's not a problem. And we can then provide registration
> handlers at bus level that either implement specific logic or just
> forward the request to the next hierarchy level (default handler).
> 
Yes, I agree with that. I just don't see the need for "priority" parameter
in this model.

--
                        Gleb.