On 2011-05-19 15:44, Anthony Liguori wrote: > On 05/19/2011 04:10 AM, 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. > > Well...... > > The i440fx may direct VGA accesses to RAM depending on the SMM > registers. By the time the PIIX gets the I/O request, we're past the > memory controller. > > This is my biggest concern about this whole notion of "priority". These > sort of issues are not dealt with by a simple z-ordering. There is > logic in each component that may be arbitrarily complex. > > We're going to end up having to dynamically change the "priority" based > how registers are programmed. But priorities are relative so it's > unclear to me how the I440FX would prioritize RAM over dispatch to PIIX > (for VGA, for instance).
But creating an extra RAM window region with higher priority than the underlying mappings. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
