On 2011-05-20 17:33, Anthony Liguori wrote: > On 05/20/2011 04:01 AM, Avi Kivity wrote: >> On 05/19/2011 07:32 PM, Anthony Liguori wrote: >>>> Think of how a window manager folds windows with priorities onto a flat >>>> framebuffer. >>>> >>>> You do a depth-first walk of the tree. For each child list, you iterate >>>> it from the lowest to highest priority, allowing later subregions >>>> override earlier subregions. >>>> >>> >>> >>> Okay, but this doesn't explain how you'll let RAM override the VGA >>> mapping since RAM is not represented in the same child list as VGA >>> (RAM is a child of the PMC whereas VGA is a child of ISA/PCI, both of >>> which are at least one level removed from the PMC). >> >> VGA will override RAM. >> >> Memory controller >> | >> +-- RAM container (prio 0) >> | >> +-- PCI container (prio 1) >> | >> +--- vga window > > Unless the RAM controller increases it's priority, right? That's how > you would implement SMM, by doing priority++? > > But if you have: > > Memory controller > | > +-- RAM container (prio 0) > | > +-- PCI container (prio 1) > | > +-- PCI-X container (prio 2) > | > +--- vga window > > Now you need to do priority = 3? > > Jan had mentioned previously about registering a new temporary window. > I assume the registration always gets highest_priority++, or do you have > to explicitly specify that PCI container gets priority=1?
The latter. And I really prefer to have this explicit over deriving the priority from the registration order. That's way too fragile/unhandy. If you decide to replace a region of lower priority later on, you need to reregister everything at that level. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
