>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
th
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, 130
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, 130
16:38, "Dutu, Alexandru via gem5-dev"
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 wond
able the refresh event of the DRAM controller.
>
>Hopefully I will have something working before the weekend.
>
>Andreas
>
>On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev"
>wrote:
>
>>Hi Mike,
>>
>>Are you running with SimpleMemory, SE or F
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 enab
, 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
F_BASE may not be used 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
>
that's done I'll post it as a review.
>>
>> 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 hav
> the segments in the GDT to be in a particular order which I don't think they
>> were.
>>
>> Gabe
>>
>> On Tue, Dec 9, 2014 at 4:22 PM, Dutu, Alexandru via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> So, I am doing this on an
t; Gabe
>
> 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 differ
4 bit mode is the same between AMD and Intel
> > CPUs. I 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,
t; >
> > On Mon, 8 Dec 2014, Gabe Black via gem5-dev wrote:
> >
> > > I'm pretty sure entering 64 bit mode is the same between AMD and
> > > Intel CPUs. I vaguely remember there being some subtle page table
> > > difference though, and gem5 is building
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 reas
Hi everyone,
There seems to be an assertion failure if O3 cpu model is ran with ruby memory
model:
444500: system.cpu.iew.lsq.thread0: Executing load PC
(0x4cd4ea=>0x4cd4f1).(1=>2), [sn:146]
444500: system.cpu.iew.lsq.thread0: Read called, load idx: 12, store idx: 20,
storeHead: 12 addr: 0x1
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
http://m5sim.org/m
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
mailto:gem5-us...@gem5.org>>
Date: Mon, Nov 1
Hi everyone,
I would like to commit the following set of patches by the end of this week.
http://reviews.gem5.org/r/2321/
http://reviews.gem5.org/r/2323/
http://reviews.gem5.org/r/2322/
http://reviews.gem5.org/r/2461/
http://reviews.gem5.org/r/2462/
http://reviews.gem5.org/r/2460/
http://reviews.
Hi everyone,
The following patches are ready to go. Please let me know if you have more
feedback or if they are ready to ship.
KVM in SE mode
http://reviews.gem5.org/r/2313/
Page Table
http://reviews.gem5.org/r/2460/
http://reviews.gem5.org/r/2462/
Thank you,
Alex
>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 [g
21 matches
Mail list logo
