From AMD's system programming manual:
SYSCALL
New selectors are loaded, without permission checking (see above), as follows:
Bits 47:32 of the STAR register specify the selector that is copied into the CS
register.
Bits 47:32 of the STAR register + 8 specify the selector that is copied into
Hi everyone,
I have been trying to run with SMT enabled in SE mode, using x86. It seems
ZeroRegister gets mapped to index 16 for the first hardware thread, which is
also register t0 that is used by the microcode. For the following hardware
threads the ZeroRegister will get mapped to 54, 92,
, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org
wrote:
Hi Andreas,
I've tried applying this patch on top of revision 8fc6e7a835d1 and I
get bunch of rejects. It seems dram_ctrl.cc is a bit different in this
patch it has all sorts of extra code to deal with ranks. So I wondering
this patch requires
.
Hopefully I will have something working before the weekend.
Andreas
On 11/12/2014 15:32, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org
wrote:
Hi Mike,
Are you running with SimpleMemory, SE or FS? On my AMD platform, for
SE, I get very similar execution times with old implementation
I don't remember of the top of my head exactly the reason to enable all those
features in the CPUID. I do remember trying not to enable things that gem5 does
not support like SSEx, SSSE and AVX. I also remember encountering problems with
libc that uses x87 instructions and pxor, so I had to
to a regular CPU.
Gabe
On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev
gem5-dev@gem5.org wrote:
Thank you for all the clarifications. I see that for SE to work on
vmx
the
TSS limit had to be extended, am and wp bits in CR0 had to be reset
and *_EFF_BASE registers
.
Gabe
On Tue, Dec 9, 2014 at 4:51 PM, Dutu, Alexandru via gem5-dev
gem5-dev@gem5.org wrote:
I haven't received any attachment to your email. So I don't have
your patch.
Alex
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
Black via gem5
by the KVM CPU, but it should be set up anyway in
case we switch back to a regular CPU.
Gabe
On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev
gem5-dev@gem5.org wrote:
Thank you for all the clarifications. I see that for SE to work on vmx
the TSS limit had to be extended, am
there being some subtle page table
difference though, and gem5 is building the page tables in SE mode
instead of the kernel.
Gabe
On Mon, Dec 8, 2014 at 7:44 PM, Dutu, Alexandru via gem5-dev
gem5-dev@gem5.org wrote:
Hi Mike,
trace-cmd is a very handy tool to get
vaguely remember there being some subtle page table difference
though, and gem5 is building the page tables in SE mode instead of the
kernel.
Gabe
On Mon, Dec 8, 2014 at 7:44 PM, Dutu, Alexandru via gem5-dev
gem5-dev@gem5.org wrote:
Hi Mike,
trace-cmd is a very handy tool
On Tue, Dec 9, 2014 at 10:06 AM, Dutu, Alexandru via gem5-dev
gem5-dev@gem5.org wrote:
Hi Adrian,
Sorry for missing your first email. I do see the interchanged segment
limits for full system mode, though I get a different behaviour on my
system. The simulation seems to hang
, Dec 9, 2014 at 4:22 PM, Dutu, Alexandru via gem5-dev
gem5-dev@gem5.org wrote:
So, I am doing this on an AMD system and I have SE working and am
able to get FS entering into virtualized mode. However, in FS I get
an early exception while the kernel is booting. This seems a bit
different
Hi Mike,
trace-cmd is a very handy tool to get an overview of what the kvm kernel module
is doing before going into gdb. In extreme cases ftrace can be useful as well.
What is the error that you are seeing? Is it still failing to enter virtualized
mode?
If that is the case and the hardware
Hi Andreas,
Sorry for the late reply, I have missed your email. I will investigate more the
issues with memory controller refresh events and let you know what I find out.
Best regards,
Alex
___
gem5-dev mailing list
gem5-dev@gem5.org
Hi Mike,
There are some patches ready to be committed for this to work.
I expect them to be committed by the end of this week.
Best regards,
Alex
-- Forwarded message --
From: Mike Upton via gem5-users
From what I see the MTRRs are not used by gem5. On a real system I would
imagine the hardware would check MTRRs and PATs to determine if an access is
uncacheable or not.
It seems that memory accesses to the range of physical addresses
[0xC000-0x] are not marked as uncacheable by
Hi Andreas,
You are right, grep -ERsonH '.{80,}$' reveales 7 lines being longer.
Sorry about this, next time I will double check. Thanks for pointing this out!
Alex
From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Andreas Hansson via
gem5-dev
17 matches
Mail list logo
