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.
> Alternatively, the chipset can instantiate the
> device (if it is an embedded one) and call m_r_add_subregion()
> itself.
>
--
Gleb.
