ron minnich wrote:
I think the bigger question that we need to answer, now that we know it's doable, is whether we want paging or not. We may not.
There's been confusion about terms such as paging and virtual memory in the past. So, to clear it up, 'paging' in this context means PGE is set in cr0
I do know what paging is. You and I even worked together on the GTT page table at the Berlin meeting last year.
Maybe my point was too subtle. You have said many times in the past, and I think it is a very good point, that we should be careful not to turn coreboot into an operating system.
One might even dare say that this is a core value of the project.
We have it today on ARM 32 and ARM V8.
Why is it helpful or neccessary there?
We will have to have it on x86_64.
Why is it neccessary there?
I was hoping it would give us a more convenient way to cover cache-disabled, write-back, and write-through ranges without all the fuss of MTRRs.
I never like quick solutions because they're usually not good.
I don't understand your comment.
I struggle when trying to explain it to Vladimir too. :\
We first had platforms with paging 12 years ago. This is quick? :-)
When it was first used for matters less than how long it has been considered for this particular use case. My concern is with the following thought process:
- MTRRs sure make for a lot of fuss. - I wish we could do something simpler. - Let's turn on paging, that would be simpler!
I'm not saying that paging would not be simpler in some ways - I'm saying that it seems like a big change, introducing codebase-wide address indirection, for seemingly small gain of avoiding fuss with MTRRs.
Oh, and since we don't have a project-wide habit of distinguishing between virtual and physical it seems that any use of paging currently in coreboot can only be a big ugly hack. :\
//Peter
On Wednesday, March 12, 2014 05:07:33 PM Peter Stuge wrote:
Oh, and since we don't have a project-wide habit of distinguishing between virtual and physical it seems that any use of paging currently in coreboot can only be a big ugly hack. :\
It would break microcode updates on VIA Nano, assuming the NDA docs I have are correct.
Alex
On Wed, Mar 12, 2014 at 9:07 AM, Peter Stuge peter@stuge.se wrote:
[on arm]
Why is it helpful or neccessary there?
It only matters if you like to have a dcache. Do you want a dcache? You must turn on paging.
On PPC, you have no choice, you can't turn off the soft TLBs on the new ones. So, you want PowerPC? It requires paging.
We will have to have it on x86_64.
Why is it neccessary there?
It only matters if you want to enter 64-bit mode. Want to enter 64-bit mode? turn on paging.
- MTRRs sure make for a lot of fuss.
- I wish we could do something simpler.
- Let's turn on paging, that would be simpler!
And, in fact, it is. It's far, far simpler. Just look at our last iteration of MTRR setup.
For the base identity map on x86-32, it's one page for 4G. For a map which locks out page 0, it's two pages.
I'm not saying that paging would not be simpler in some ways - I'm saying that it seems like a big change, introducing codebase-wide address indirection, for seemingly small gain of avoiding fuss with MTRRs.
No, there's much more to it than that, as I've explained.
And, again, we've had virtual addresses forever. That's what segmentation hardware does. We just had a 1:1 mapping. As we do on ARM today.
ron
-
mrnuke -
Peter Stuge -
ron minnich