For that we might want two walkers. They'd need to start with
different CR3s (roots), interleave, etc. and doing it all in one might
be overly complicated. I honestly haven't thought about it deeply.
That's with AMD's SVM too, mind you, since I think Intel's VT uses a
substantially different structure for the hypervisor level page
tables. Why would they do that? I have no idea.
Gabe
Quoting Steve Reinhardt <[email protected]>:
Note that if/when we get around to supporting virtualization, we'll
need to handle nested page table walks too, so if there's a solution
to this problem that looks like it would lend itself better to nesting
walks too then that would be a preferable direction to go.
Steve
On Wed, Aug 18, 2010 at 8:14 PM, Gabriel Michael Black
<[email protected]> wrote:
Off hand I would say yes, queuing up a second request behind one that caused
a table walk makes sense. Since there should only be one other request, just
having a variable for the on deck request should be sufficient instead of a
full blown queue. Please let me know if you think otherwise. I'll think
about it some more and let you know if I change my mind, but I think that
makes sense.
Gabe
Quoting Joel Hestness <[email protected]>:
Hi,
I am currently running a benchmark in X86_FS timing mode (single or
multicore) that crashes due to the page table walker. On a data write (or
read) instruction that causes TimingSimpleCPU::write to split the TLB
access
into two accesses (cpu/simple/timing.cc:~560), if the first TLB access
misses, it causes the page table walker to start a walk and its state =
Waiting. Since the second access happens immediately
in TimingSimpleCPU::write, if the second request also misses, it causes
another walk that fails the (state == Ready) assertion in
X86ISA::Walker::start (arch/x86/pagetable_walker.cc:~316).
Seems this is a corner case of a corner case, namely, an unaligned
(split)
data access, whose split TLB accesses both miss. It doesn't look like
there
is any code to handle the situation yet, and I'm hoping to get some
guidance
on how to address it.
It seems to me that since this only happens on a TLB miss, that the TLB
or
walker should be able to handle the multiple requests. I see that in the
ARM code, the page table walker has a queue of walks that are currently in
flight (I'm having trouble convincing myself that the queues can't
conflict
when multiple walks are in flight :\). Would it make sense to have
similar
state queuing in the x86 page table walker?
Thanks,
Joel
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Texas - Austin
http://www.cs.utexas.edu/~hestness
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
