Review Board 2.0.15


Config: Keep track of uncached and cached ports separately.

Review Request #455 - Created Jan. 29, 2011 and submitted

Information
Gabe Black
gem5
Reviewers
Default
ali, gblack, nate, stever 
Config: Keep track of uncached and cached ports separately.

This makes sure that the address ranges requested for caches and uncached ports
don't conflict with each other, and that accesses which are always uncached
(message signaled interrupts for instance) don't waste time passing through
caches.

   

  


 


 

  

  









  
 


  

 


















 

  


 


  




   
Ship it!



   

   
Ali Saidi

   
Posted  (Jan. 30, 2011, 9:18 a.m.)


  


  


  

   
Before you could commit could you run arm/fs with and without and diff config.ini to make sure there aren't any silent changes happening there.




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    Done
    
    
    
   
    2. 

   


  





  

 


  

 

















 



 

  


 


  



   

   
Steve Reinhardt

   
Posted  (Jan. 30, 2011, 11:14 p.m.)


  


  


  

   
I don't see why this is necessary.
1. I don't think caches request address ranges, they are just the default responder on buses where they sit on the memory-side of the bus.
2. As far as the timing issue, I don't know whether this diff makes things more realistic, but if timing is an issue then we ought to be able to just change the cache code to make it pass uncached accesses through more quickly.

I don't think it's bad, necessarily, it just appears to be fixing something that I thought already worked, so if it's broken I'd like to understand better what the problem is before we commit to this being the fix.  My apologies if I missed some previous email discussion; I've been bad about keeping up with m5-dev email lately.

And why does it apply to x86 only?  Is there something special about x86 that requires this?



  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    I don't think 1 is correct. Caches request an address range, it just defaults to the whole address space. I'm guessing that's so you can set up banked caches. I implemented this because M5 wouldn't work without it because the none memory ports were conflicting with the cache address ranges. For 2, I wasn't talking about simulated time, I was talking mostly about simulated time. The uncached accesses would pass through unmolested (assuming there wasn't something with a transmission delay) but then you'd have to poke each cache, port interface, and intermediate bus on the way. This isn't really a big change, it's just making the config scripts route some ports through caches and some around them. I really doubt interrupt traffic on a real CPU goes through the cache, although I don't know that for a fact.

The reason it's specific to x86, or really only came up now with x86, is that the CPUs in x86 have devices in them (interrupt controllers) that need to get messages from the devices (interrupt messages). No other ISA makes the CPU a target for packets, so no other ISA caused a conflict with the caches.

This also cleans up some hackiness as far as how physmem_port was being handled, although it's possible that could have been eliminated regardless.
    
    
    
   
    2.