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.
Do we want block device drivers? Do we want SMP? Do we want processes? Do we want runtime service? Do we want ACPI? Do we want closed blobs? Do we want paging?
ron minnich wrote:
We've gone backwards in some ways from when Linux was our bootstrap.
I think the bigger question is what we want to do in the future.
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.
//Peter
On Wed, Mar 12, 2014 at 6:33 AM, Peter Stuge peter@stuge.se wrote:
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, meaning we have virtual address translation via page tables. It does not imply we are swapping to disk, a.k.a. swapping or virtual memory.
It means there is a mapping from a virtual address to a physical address. We've always had virtual addressing, in fact: it's there the instant you do an LGDT. It's just that it's a 1:1 mapping. That's why I like to say paging -- it's a commonly used term to mean 'virtual address translation via page tables' and it's a lot shorter to type. We could also call it VATPT :-)
For the most part, the paging patch does the same thing as virtual addressing via segments -- provide a 1:1 mapping, save for locking out page 0. Locking out page 0 is what we do on ARM as well. It catches NULL pointer errors.
Do we want block device drivers?
We have them. Thanks to the continuing cleverness of the hardware vendors, we need them just to access SPI on many new platforms.
Do we want SMP?
We've had it since 2002 with K8. We haven't used it much, but it's there. It's mainly used to init the CPU, but in the past we had experiments with parallel memory configuration and/or parallel memory clearing.
Do we want processes?
We have threads. We might want processes. Who knows? But it's a much bigger effort.
Do we want runtime service?
We have it with ACPI/SMI.
Do we want ACPI?
We've had it for years. Do we want UEFI runtime services? They're required for ARM V8 ;-(
Do we want closed blobs?
We can't boot without them on many new platforms.
Do we want paging?
As per my clarification above, I think we want virtual address translation via page tables, a.k.a. paging. I'm continuing to work with it to see. Note that we had virtual addressing on Alpha on LinuxBIOS 1.0 via PALcode. I am pretty sure we also had it on PPC. We have it today on ARM 32 and ARM V8. We will have to have it on x86_64.
x86 32-bit will be the single sole system without virtual address translation via page tables. At the moment, the experiment is looking pretty good.
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. We first had platforms with paging 12 years ago. This is quick? :-)
ron
-
Peter Stuge -
ron minnich