Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

You are right Nilay. I sent an email last week but nobody has replied. It seems that descriptors (cdDesc, dsDesc and tssDesc) located in src/arch/x86/system.cc file are not well-initialized and as a consequence kvm does not work when running in full-system mode. Segment limits values (limitHigh a

[gem5-dev] Cron /z/m5/regression/do-regression quick

* build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linu

Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/ --- (Updated Dec. 9, 2014, 3:15 p.m.) Review request for Default. Summary (updated) -

Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/#review5655 --- Ship it! Ship It! - Andreas Hansson On Dec. 9, 2014, 3:15 p.m., Nilay

Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/#review5656 --- Ship it! Ship It! - Jason Power On Dec. 9, 2014, 3:15 p.m., Nilay Vai

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

Will someone be providing a patch for this? I am happy to test it. From Adrian's description it seems there are a bunch of issues. On Tue, Dec 9, 2014 at 12:09 AM, Adrián Colaso Diego via gem5-dev < gem5-dev@gem5.org> wrote: > You are right Nilay. I sent an email last week but nobody has replie

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

Hi Adrian, Sorry for missing your first email. I have solved the interchanged segment limits and other bits in segment descriptors for full system mode, though I get a different behavior on my system. The simulation seems to hang in the following manner: Processor #0 (Bootup-CPU) I/O APIC #1 a

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

I'm working on a patch to overhaul the segment setup stuff. Gabe On Tue, Dec 9, 2014 at 11:36 AM, Dutu, Alexandru via gem5-dev < gem5-dev@gem5.org> wrote: > Hi Adrian, > > Sorry for missing your first email. I have solved the interchanged segment > limits and other bits in segment descriptors fo

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

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 in the following manner: Processor #0 (Bootup-CPU) I/O APIC #1 at 0xFEC0. Setting APIC routing to flat

Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/#review5657 --- src/mem/ruby/system/RubyPort.cc

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

I have FS working again which is good, but I'm still having problems with SE. If you could let me know what you did to get things going that would be very helpful. 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 yo

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

Oh, I see you have FS working again and not SE. NM, I'll keep looking. Gabe On Tue, Dec 9, 2014 at 4:04 PM, Gabe Black wrote: > I have FS working again which is good, but I'm still having problems with > SE. If you could let me know what you did to get things going that would be > very helpful.

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

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 from what Nilay and Adrian observed for FS. Could you please share the diffs that got F

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

Here is my patch so far. There were a few things wrong, although I didn't really keep notes. The limits were mixed up, the long mode bit was set on all descriptors when it's only valid for the code segment, privilege level 0 is the OS and 3 is for applications and not the other way around, and I th

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

Oh, also segment limits weren't being computed correctly in the installSegDesc function, although I don't think that was from the KVM stuff. Once it was fixed it required adjusting the KVM stuff a little, though. Gabe On Tue, Dec 9, 2014 at 4:29 PM, Gabe Black wrote: > Here is my patch so far.

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

And... it turns out the KVM change wasn't necessary. If you're working from my patch, get rid of where the segment limit is divided by PageBytes. That was only necessary because I wasn't adding 0xFFF to the limit when the granularity bit was set. Gabe On Tue, Dec 9, 2014 at 4:31 PM, Gabe Black w

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

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-dev Sent: Tuesday, December 09, 2014 6:42 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm

Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports

On Tue, 9 Dec 2014, Brad Beckmann wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/#review5657 --- src/mem/ruby/system/RubyPort

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

It was attached in my sent mail. Maybe it's being blocked by something? I'm hunting down another problem so I don't want to move my tree around too much, but once 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: >

Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports

I looked at this a long time ago and I concluded it would add more complexity to the tester than I wanted to add. Since then, we have built additional testers that don't understand retries. I would strongly prefer we keep it and I'm not sure why you want to remove it. Can we just move this co

Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/#review5658 --- src/mem/ruby/system/RubyPort.cc

[gem5-dev] exit status of simpoint samples

I am running a set of checkpointed samples via the new simpoint patch. it seems that when the simulation ends at the end of the sample, gem5 returns a non-zero code (127 I think). Is this intended? when gem5 reaches the end of the program via exit() it returns 0. ___

[gem5-dev] Review Request 2557: imported patch wip.patch

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2557/ --- Review request for Default. Repository: gem5 Description --- Changeset 10605

Re: [gem5-dev] Review Request 2557: imported patch wip.patch

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2557/#review5659 --- Posted for reference, don't review yet. - Gabe Black On Dec. 10, 2014,

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

I figured out what the other problem was, so here's the review. http://reviews.gem5.org/r/2557/ Gabe On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black wrote: > It was attached in my sent mail. Maybe it's being blocked by something? > I'm hunting down another problem so I don't want to move my tree ar

Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports

On Tue, Dec 9, 2014 at 7:17 PM, Joel Hestness via gem5-dev < gem5-dev@gem5.org> wrote: > > So, I'm not sure I follow how this can work... The RubySequencer can > still block a request if (1) a master issues accesses in excess of the > sequencer's outstanding request count, or (2) the master is

[gem5-dev] changeset in gem5: Let other objects set up memory like regions ...

changeset 8fc6e7a835d1 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=8fc6e7a835d1 description: Let other objects set up memory like regions in a KVM VM. diffstat: src/cpu/kvm/vm.cc | 80 -- src/cpu/kvm/vm.hh |

Re: [gem5-dev] Review Request 2510: Let other objects set up memory like regions in a KVM VM.

> On Dec. 8, 2014, 2:36 p.m., Andreas Hansson wrote: > > src/cpu/kvm/vm.cc, line 374 > > > > > > I think this causes problems with some of the officially supported > > compilers. It's just a hunch, but please check. > > Ga

Re: [gem5-dev] Review Request 2276: ruby: don't make O3 CPU squash on loads that hit outstanding requests

Hi Nilay, The bottom line is that there was an inconsistency between GEMS and M5 in terms of where coalescing of requests to a single cache line should take place; in M5 this took place in the L1 cache (and the "classic" gem5 cache continues to do so), while in GEMS this apparently took place in t

Re: [gem5-dev] Review Request 2514: scons: Make the USE_KVM variable available in C++.

> On Nov. 19, 2014, 3:33 p.m., Andreas Sandberg wrote: > > The change itself makes sense, but I'd really prefer if we could avoid > > conditional compilation and use a kvm-agnostic interface to handle device > > memory. See my reply in the email thread for RB #2513. > > > > Consider this a "sh

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

Ok, I got SE working too. I'll clean up my patch and send that out in a bit. Gabe On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black wrote: > I figured out what the other problem was, so here's the review. > > http://reviews.gem5.org/r/2557/ > > Gabe > > On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black wrot