<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 12, 2014 at 6:33 AM, Peter Stuge <span dir="ltr"><<a href="mailto:peter@stuge.se" target="_blank">peter@stuge.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">ron minnich wrote:<br>
> I think the bigger question that we need to answer, now that we know<br>
> it's doable, is whether we want paging or not. We may not.<br></div></blockquote><div><br></div><div><br></div><div>There's been confusion about terms such as paging and virtual memory in the past. So, to clear it up, </div>
<div>'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 </div><div>swapping to disk, a.k.a. swapping or virtual memory. </div><div>
<br></div><div>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</div><div>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 :-)</div>
<div><br></div><div>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</div><div>page 0. Locking out page 0 is what we do on ARM as well. It catches NULL pointer errors.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
</div>Do we want block device drivers?</blockquote><div><br></div><div>We have them. Thanks to the continuing cleverness of the hardware vendors, we need them just to access SPI on many new platforms. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Do we want SMP?</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Do we want processes?<br></blockquote><div><br></div><div>We have threads. We might want processes. Who knows? But it's a much bigger effort. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do we want runtime service? </blockquote><div><br></div><div>We have it with ACPI/SMI.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Do we want ACPI?</blockquote>
<div><br></div><div>We've had it for years. Do we want UEFI runtime services? They're required for ARM V8 ;-(</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Do we want closed blobs?<br></blockquote><div><br></div><div>We can't boot without them on many new platforms.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Do we want paging?<br></blockquote><div><br></div><div>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.</div><div>Note that we had virtual addressing on Alpha on LinuxBIOS 1.0 via PALcode. I am pretty sure we also </div>
<div>had it on PPC. We have it today on ARM 32 and ARM V8. We will have to have it on x86_64.</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> I was hoping it would give us a more convenient way to cover<br>
> cache-disabled, write-back, and write-through ranges without<br>
> all the fuss of MTRRs.<br>
<br>
</div>I never like quick solutions because they're usually not good.<br></blockquote><div><br></div><div>I don't understand your comment. We first had platforms with paging 12 years ago. This is quick? :-)</div><div>
<br></div><div>ron </div></div></div></div>