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

[Gabe Black via gem5-dev]

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  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 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:
>>
>>> 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 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  wrote:
>>>
>>> > 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. 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 think the type was being set wrong for one of the segments.
>>> >> Also, the syscall and sysenter registers (star and friends) require
>>> >> 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 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 FS working?
>>> >>>
>>> >>> Thanks,
>>> >>> 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:07 PM
>>> >>> To: gem5 Developer List
>>> >>> Subject: 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.
>>> >>> >
>>> >>> > 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 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
>>> >>> >> Processors: 1
>>> >>> >> PANIC: early exception rip 807909a9 error 9 cr2
>>> >>> >> ff5fd020
>>> >>> >>
>>> >>> >> Can please provide a patch with all the modifications that fixed
>>> >>> >> the issue on your system?
>>> >>> >>
>>> >>> >> Thank you,
>>> >>> >> Alex
>>> >>> >> 
>>> >>> >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián
>>> >>> >> Colaso Diego via gem5-dev [gem5-dev@gem5.org]
>>> >>> >> Sent: Tuesday, December 09, 2014 2:09 AM
>>> >>> >> To: gem5 Developer List
>>> >>> >> Subject: 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 v

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

[Gabe Black via gem5-dev]

> 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 "ship it" if it really turns out that using conditional 
> > compilation is the way to go.

This is next in the series. The dependent change it was originally needed for 
is gone, but now it's needed for http://reviews.gem5.org/r/2526/.


- Gabe


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2514/#review5488
---


On Nov. 19, 2014, 6:44 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2514/
> ---
> 
> (Updated Nov. 19, 2014, 6:44 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10548:07c3cbac4cdd
> ---
> scons: Make the USE_KVM variable available in C++.
> 
> We need it to determine whether we should expect KVM related parameters
> exist in the cirrus graphics device.
> 
> 
> Diffs
> -
> 
>   SConstruct 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 
> 
> Diff: http://reviews.gem5.org/r/2514/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe Black
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Steve Reinhardt via gem5-dev]

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 the CPU
model, which led Ruby to assume something was wrong if it got another
access to a line which already had an access outstanding.

Adding coalescing to the Sequencer makes Ruby behave like the classic M5
cache, which makes O3 happy, as it avoids unnecessary and unrealistic
pipeline replays on accesses that should be coalesced.

I'm not sure to what extent the changeset
http://repo.gem5.org/gem5/rev/6be8945d226b ameliorates the problem, but it
doesn't directly address the real issue, which is that the current Ruby and
classic caches have different expectations of the CPU model, which isn't
right.

Steve


On Thu, Dec 4, 2014 at 10:45 AM, Beckmann, Brad 
wrote:

> Nilay,
>
> Coalescing and buffering requests in the Sequencer is very important for
> good performance.  As long as we have a per address interface between our
> CPU/GPU models and Ruby, we need to cache block optimizations in Ruby.
>
> Brad
>
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay
> Vaish via gem5-dev
> Sent: Thursday, December 04, 2014 7:36 AM
> To: Nilay Vaish; Steve Reinhardt; Default
> Subject: Re: [gem5-dev] Review Request 2276: ruby: don't make O3 CPU
> squash on loads that hit outstanding requests
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2276/#review5621
> ---
>
>
> Steve, is it all right to buffer requests in the Sequencer?  I am not even
> in favor of having a sequencer and buffering requests makes it worse.
>
>
> src/mem/ruby/system/Sequencer.cc
> 
>
> initialize to false?
>
>
> - Nilay Vaish
>
>
> On June 21, 2014, 5 p.m., Steve Reinhardt wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://reviews.gem5.org/r/2276/
> > ---
> >
> > (Updated June 21, 2014, 5 p.m.)
> >
> >
> > Review request for Default.
> >
> >
> > Repository: gem5
> >
> >
> > Description
> > ---
> >
> > Changeset 10240:b01d667ec431
> > ---
> > ruby: don't make O3 CPU squash on loads that hit outstanding requests
> >
> > Mismatch between O3 and Ruby in handling aliased requests: Ruby
> > returns false when it sees aliased request or memory blocked. O3
> > squash and refetch when it sees false signal from Ruby.
> >
> > Fix: Merging readRequestTable and writeRequestTable in a single table
> > that maps requesting address and all requests that are aliased with
> > the address.
> >
> > This work was done while Binh was an intern at AMD Research.
> >
> >
> > Diffs
> > -
> >
> >   src/mem/packet.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >   src/mem/protocol/RubySlicc_Exports.sm
> b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >   src/mem/ruby/system/DMASequencer.hh
> b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >   src/mem/ruby/system/DMASequencer.cc
> b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >   src/mem/ruby/system/RubyPort.hh
> b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >   src/mem/ruby/system/RubyPort.cc
> b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >   src/mem/ruby/system/RubyPortProxy.hh
> b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >   src/mem/ruby/system/RubyPortProxy.cc
> b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >   src/mem/ruby/system/Sequencer.hh
> b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >   src/mem/ruby/system/Sequencer.cc
> > b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
> >
> > Diff: http://reviews.gem5.org/r/2276/diff/
> >
> >
> > Testing
> > ---
> >
> >
> > Thanks,
> >
> > Steve Reinhardt
> >
> >
>
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Gabe Black via gem5-dev]

> 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.
> 
> Gabe Black wrote:
> Ugh. Yes, I think you're right. That's standard C but not C++.

I changed it to just initialize the elements one by one.


- Gabe


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2510/#review5653
---


On Nov. 23, 2014, 2:51 p.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2510/
> ---
> 
> (Updated Nov. 23, 2014, 2:51 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10551:7767dc21318d
> ---
> Let other objects set up memory like regions in a KVM VM.
> 
> 
> Diffs
> -
> 
>   src/cpu/kvm/vm.hh f9fb64a72259a2514080151b5250a04c575d443a 
>   src/cpu/kvm/vm.cc f9fb64a72259a2514080151b5250a04c575d443a 
> 
> Diff: http://reviews.gem5.org/r/2510/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe Black
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Gabe Black via gem5-dev]

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 |  60 ++--
 2 files changed, 127 insertions(+), 13 deletions(-)

diffs (221 lines):

diff -r 4e09ae443c96 -r 8fc6e7a835d1 src/cpu/kvm/vm.cc
--- a/src/cpu/kvm/vm.cc Mon Dec 08 04:49:53 2014 -0500
+++ b/src/cpu/kvm/vm.cc Tue Dec 09 21:53:44 2014 -0800
@@ -1,4 +1,5 @@
 /*
+ * Copyright 2014 Google, Inc.
  * Copyright (c) 2012 ARM Limited
  * All rights reserved
  *
@@ -124,6 +125,16 @@
 return checkExtension(KVM_CAP_COALESCED_MMIO);
 }
 
+int
+Kvm::capNumMemSlots() const
+{
+#ifdef KVM_CAP_NR_MEMSLOTS
+return checkExtension(KVM_CAP_NR_MEMSLOTS);
+#else
+return 0;
+#endif
+}
+
 bool
 Kvm::capOneReg() const
 {
@@ -288,6 +299,10 @@
   started(false),
   nextVCPUID(0)
 {
+maxMemorySlot = kvm.capNumMemSlots();
+/* If we couldn't determine how memory slots there are, guess 32. */
+if (!maxMemorySlot)
+maxMemorySlot = 32;
 /* Setup the coalesced MMIO regions */
 for (int i = 0; i < params->coalescedMMIO.size(); ++i)
 coalesceMMIO(params->coalescedMMIO[i]);
@@ -323,7 +338,13 @@
 DPRINTF(Kvm, "Mapping region: 0x%p -> 0x%llx [size: 0x%llx]\n",
 pmem, range.start(), range.size());
 
-setUserMemoryRegion(slot, pmem, range, 0 /* flags */);
+if (range.interleaved()) {
+panic("Tried to map an interleaved memory range into "
+  "a KVM VM.\n");
+}
+
+const MemSlot slot = allocMemSlot(range.size());
+setupMemSlot(slot, pmem, range.start(), 0/* flags */);
 } else {
 DPRINTF(Kvm, "Zero-region not mapped: [0x%llx]\n", range.start());
 hack("KVM: Zero memory handled as IO\n");
@@ -331,17 +352,58 @@
 }
 }
 
+const KvmVM::MemSlot
+KvmVM::allocMemSlot(uint64_t size)
+{
+if (!size)
+panic("Memory slots must have non-zero size.\n");
+
+std::vector::iterator pos;
+for (pos = memorySlots.begin(); pos != memorySlots.end(); pos++) {
+if (!pos->size) {
+pos->size = size;
+pos->active = false;
+return pos->slot;
+}
+}
+
+uint32_t nextSlot = memorySlots.size();
+if (nextSlot > maxMemorySlot)
+panic("Out of memory slots.\n");
+
+MemorySlot slot;
+slot.size = size;
+slot.slot = nextSlot;
+slot.active = false;
+
+memorySlots.push_back(slot);
+return MemSlot(slot.slot);
+}
+
 void
-KvmVM::setUserMemoryRegion(uint32_t slot,
-   void *host_addr, AddrRange guest_range,
-   uint32_t flags)
+KvmVM::setupMemSlot(const KvmVM::MemSlot num, void *host_addr, Addr guest,
+uint32_t flags)
 {
-if (guest_range.interleaved())
-panic("Tried to map an interleaved memory range into a KVM VM.\n");
+MemorySlot &slot = memorySlots.at(num.num);
+slot.active = true;
+setUserMemoryRegion(num.num, host_addr, guest, slot.size, flags);
+}
 
-setUserMemoryRegion(slot, host_addr,
-guest_range.start(), guest_range.size(),
-flags);
+void
+KvmVM::disableMemSlot(const KvmVM::MemSlot num)
+{
+MemorySlot &slot = memorySlots.at(num.num);
+if (slot.active)
+setUserMemoryRegion(num.num, NULL, 0, 0, 0);
+slot.active = false;
+}
+
+void
+KvmVM::freeMemSlot(const KvmVM::MemSlot num)
+{
+disableMemSlot(num.num);
+MemorySlot &slot = memorySlots.at(num.num);
+slot.size = 0;
 }
 
 void
diff -r 4e09ae443c96 -r 8fc6e7a835d1 src/cpu/kvm/vm.hh
--- a/src/cpu/kvm/vm.hh Mon Dec 08 04:49:53 2014 -0500
+++ b/src/cpu/kvm/vm.hh Tue Dec 09 21:53:44 2014 -0800
@@ -1,4 +1,5 @@
 /*
+ * Copyright 2014 Google, Inc.
  * Copyright (c) 2012 ARM Limited
  * All rights reserved
  *
@@ -110,6 +111,12 @@
 int capCoalescedMMIO() const;
 
 /**
+ * Attempt to determine how many memory slots are available. If it can't
+ * be determined, this function returns 0.
+ */
+int capNumMemSlots() const;
+
+/**
  * Support for reading and writing single registers.
  *
  * @see BaseKvmCPU::getOneReg(), and BaseKvmCPU::setOneReg()
@@ -331,6 +338,42 @@
 bool hasKernelIRQChip() const { return _hasKernelIRQChip; }
 /** @} */
 
+struct MemSlot
+{
+MemSlot(uint32_t _num) : num(_num)
+{}
+MemSlot() : num(-1)
+{}
+
+int32_t num;
+};
+
+/**
+ *  Allocate a memory slot within the VM.
+ */
+const MemSlot allocMemSlot(uint64_t size);
+
+/**
+ * Setup a region of physical memory in the guest
+ *
+ * @param slot KVM memory slot ID returned by allocMemSlot
+ * @param host_addr Memor

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

[Steve Reinhardt via gem5-dev]

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 issues an access
> for a cache line with an existing outstanding access. Are there no mainline
> gem5 masters (e.g. CPU cores) that rely on the retry signal to restart
> injection after bumping up against either of these blocking conditions?
> Gem5-gpu GPU LSQs currently rely on the Sequencer retry signals.


I admit I am confused by the situation here too.  As Alex mentioned in
another post, we were not having any problems with the code that Nilay is
removing here until we recently updated our tree, and we tracked our
problems down to this changeset: http://repo.gem5.org/gem5/rev/6be8945d226b.
I would like to see a definitive explanation that it's this code that's
wrong and should be removed, and not this other changeset that's the
problem, before we make any drastic changes like this.

Steve
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Gabe Black via gem5-dev]

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 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:
>
>> 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 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  wrote:
>>
>> > 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. 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 think the type was being set wrong for one of the segments.
>> >> Also, the syscall and sysenter registers (star and friends) require
>> >> 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 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 FS working?
>> >>>
>> >>> Thanks,
>> >>> 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:07 PM
>> >>> To: gem5 Developer List
>> >>> Subject: 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.
>> >>> >
>> >>> > 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 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
>> >>> >> Processors: 1
>> >>> >> PANIC: early exception rip 807909a9 error 9 cr2
>> >>> >> ff5fd020
>> >>> >>
>> >>> >> Can please provide a patch with all the modifications that fixed
>> >>> >> the issue on your system?
>> >>> >>
>> >>> >> Thank you,
>> >>> >> Alex
>> >>> >> 
>> >>> >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián
>> >>> >> Colaso Diego via gem5-dev [gem5-dev@gem5.org]
>> >>> >> Sent: Tuesday, December 09, 2014 2:09 AM
>> >>> >> To: gem5 Developer List
>> >>> >> Subject: 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 and limitLow) are interchanged
>> >>> >> and several segment descriptor values are wrong too. If these
>> >>> >> values are corrected kvm works again as before.
>> >>> >>
>> >>> >> Adrian
>> >>> >>
>> >>> >> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vais

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

[Gabe Black via gem5-dev]

---
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, 5:32 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 5:32 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10605:edee8f168abd
> ---
> imported patch wip.patch
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 
>   src/arch/x86/regs/misc.hh 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 
>   src/arch/x86/system.cc 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 
>   src/arch/x86/utility.hh 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 
>   src/cpu/kvm/x86_cpu.cc 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 
> 
> Diff: http://reviews.gem5.org/r/2557/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe Black
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Gabe Black via gem5-dev]

---
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:edee8f168abd
---
imported patch wip.patch


Diffs
-

  src/arch/x86/process.cc 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 
  src/arch/x86/regs/misc.hh 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 
  src/arch/x86/system.cc 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 
  src/arch/x86/utility.hh 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 
  src/cpu/kvm/x86_cpu.cc 4e09ae443c9668f4b09e7fa339c2e02dc9a7435a 

Diff: http://reviews.gem5.org/r/2557/diff/


Testing
---


Thanks,

Gabe Black

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] exit status of simpoint samples

[mike upton via gem5-dev]

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 mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Joel Hestness via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2549/#review5658
---



src/mem/ruby/system/RubyPort.cc


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 issues an access for a cache line 
with an existing outstanding access. Are there no mainline gem5 masters (e.g. 
CPU cores) that rely on the retry signal to restart injection after bumping up 
against either of these blocking conditions? Gem5-gpu GPU LSQs currently rely 
on the Sequencer retry signals.


- Joel Hestness


On Dec. 9, 2014, 3:15 p.m., Nilay Vaish wrote:
> 
> ---
> 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.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10602:d3bb9d95bf76
> ---
> ruby: ruby port: do not check for blocked ports
> RubyPort used to maintain a list of blocked ports which are sent retries when
> the port becomes unblocked.  This is unnecessary since RubyPort's port 
> definitions
> inherit from QueuedPort.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/system/RubyPort.hh 6efb37480d87 
>   src/mem/ruby/system/RubyPort.cc 6efb37480d87 
> 
> Diff: http://reviews.gem5.org/r/2549/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay Vaish
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Beckmann, Brad via gem5-dev]

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 condition to 
QueuedPort? 

In general, my preference is to have fewer retries between the core models and 
Ruby.  We should only be doing retries when we have structural hazards and the 
testers should not be running in an environment where structures are limited.  
The testers are used to stress the logic and work best when we allow big burst 
of requests.

Brad


-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Tuesday, December 09, 2014 4:56 PM
To: Beckmann, Brad
Cc: Default
Subject: Re: 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.cc
> 
>
>Why are you removing these lines?  Is the tester now aware when the
>port is blocked and does it handle retries correctly?  I would prefer
>if it did not.  We want the tester to be as aggressive as possible.

I am aware that the tester needs to change.  Brad, is there any problem if the 
tester just tries to send packets even when the port is blocked?  At most it 
would fail.

--
Nilay
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Gabe Black via gem5-dev]

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:

> 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 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  wrote:
>
> > 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. 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 think the type was being set wrong for one of the segments.
> >> Also, the syscall and sysenter registers (star and friends) require
> >> 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 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 FS working?
> >>>
> >>> Thanks,
> >>> 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:07 PM
> >>> To: gem5 Developer List
> >>> Subject: 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.
> >>> >
> >>> > 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 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
> >>> >> Processors: 1
> >>> >> PANIC: early exception rip 807909a9 error 9 cr2
> >>> >> ff5fd020
> >>> >>
> >>> >> Can please provide a patch with all the modifications that fixed
> >>> >> the issue on your system?
> >>> >>
> >>> >> Thank you,
> >>> >> Alex
> >>> >> 
> >>> >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián
> >>> >> Colaso Diego via gem5-dev [gem5-dev@gem5.org]
> >>> >> Sent: Tuesday, December 09, 2014 2:09 AM
> >>> >> To: gem5 Developer List
> >>> >> Subject: 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 and limitLow) are interchanged
> >>> >> and several segment descriptor values are wrong too. If these
> >>> >> values are corrected kvm works again as before.
> >>> >>
> >>> >> Adrian
> >>> >>
> >>> >> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev
> >>> escribió:
> >>> >> > I also faced problem in getting KVM CPU to run in FS mode.  I
> >>> >> > figured
> >>> >> that
> >>> >> > the following changeset causes problems:
> >>> >> >
> >>> >> > authorAlexandru Dutu 
> >>> >> >   Sun Nov 23 18:01:08 2014 -0800 (2

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

[Nilay Vaish via gem5-dev]

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.cc


   Why are you removing these lines?  Is the tester now aware when the
   port is blocked and does it handle retries correctly?  I would prefer
   if it did not.  We want the tester to be as aggressive as possible.


I am aware that the tester needs to change.  Brad, is there any problem if 
the tester just tries to send packets even when the port is blocked?  At 
most it would fail.


--
Nilay
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Dutu, Alexandru via gem5-dev]

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 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  wrote:

> 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. 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 think the type was being set wrong for one of the segments. 
>> Also, the syscall and sysenter registers (star and friends) require 
>> 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 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 FS working?
>>>
>>> Thanks,
>>> 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:07 PM
>>> To: gem5 Developer List
>>> Subject: 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.
>>> >
>>> > 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 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
>>> >> Processors: 1
>>> >> PANIC: early exception rip 807909a9 error 9 cr2
>>> >> ff5fd020
>>> >>
>>> >> Can please provide a patch with all the modifications that fixed 
>>> >> the issue on your system?
>>> >>
>>> >> Thank you,
>>> >> Alex
>>> >> 
>>> >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián 
>>> >> Colaso Diego via gem5-dev [gem5-dev@gem5.org]
>>> >> Sent: Tuesday, December 09, 2014 2:09 AM
>>> >> To: gem5 Developer List
>>> >> Subject: 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 and limitLow) are interchanged 
>>> >> and several segment descriptor values are wrong too. If these 
>>> >> values are corrected kvm works again as before.
>>> >>
>>> >> Adrian
>>> >>
>>> >> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev
>>> escribió:
>>> >> > I also faced problem in getting KVM CPU to run in FS mode.  I 
>>> >> > figured
>>> >> that
>>> >> > the following changeset causes problems:
>>> >> >
>>> >> > authorAlexandru Dutu 
>>> >> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
>>> >> > changeset 10554   fe2e2f06a7c8
>>> >> >
>>> >> > I saw the hardware reason 0x8021, but did not try to figure 
>>> >> > what was going on wrong.
>>> >> >
>>> >> > --
>>> >> > Nilay
>>> >> >
>>> >> > 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 the pa

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

[Gabe Black via gem5-dev]

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  wrote:

> 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. 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
>> think the type was being set wrong for one of the segments. Also, the
>> syscall and sysenter registers (star and friends) require 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 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
>>> FS working?
>>>
>>> Thanks,
>>> 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:07 PM
>>> To: gem5 Developer List
>>> Subject: 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.
>>> >
>>> > 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 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
>>> >> Processors: 1
>>> >> PANIC: early exception rip 807909a9 error 9 cr2
>>> >> ff5fd020
>>> >>
>>> >> Can please provide a patch with all the modifications that fixed the
>>> >> issue on your system?
>>> >>
>>> >> Thank you,
>>> >> Alex
>>> >> 
>>> >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián Colaso
>>> >> Diego via gem5-dev [gem5-dev@gem5.org]
>>> >> Sent: Tuesday, December 09, 2014 2:09 AM
>>> >> To: gem5 Developer List
>>> >> Subject: 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 and limitLow) are interchanged and
>>> >> several segment descriptor values are wrong too. If these values are
>>> >> corrected kvm works again as before.
>>> >>
>>> >> Adrian
>>> >>
>>> >> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev
>>> escribió:
>>> >> > I also faced problem in getting KVM CPU to run in FS mode.  I
>>> >> > figured
>>> >> that
>>> >> > the following changeset causes problems:
>>> >> >
>>> >> > authorAlexandru Dutu 
>>> >> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
>>> >> > changeset 10554   fe2e2f06a7c8
>>> >> >
>>> >> > I saw the hardware reason 0x8021, but did not try to figure
>>> >> > what was going on wrong.
>>> >> >
>>> >> > --
>>> >> > Nilay
>>> >> >
>>> >> > 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 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 an overview of what the
>>> >> > >> kvm
>>> >> kernel
>>> >> > >> module is doi

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

[Gabe Black via gem5-dev]

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. 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
> think the type was being set wrong for one of the segments. Also, the
> syscall and sysenter registers (star and friends) require 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 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
>> FS working?
>>
>> Thanks,
>> 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:07 PM
>> To: gem5 Developer List
>> Subject: 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.
>> >
>> > 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 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
>> >> Processors: 1
>> >> PANIC: early exception rip 807909a9 error 9 cr2
>> >> ff5fd020
>> >>
>> >> Can please provide a patch with all the modifications that fixed the
>> >> issue on your system?
>> >>
>> >> Thank you,
>> >> Alex
>> >> 
>> >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián Colaso
>> >> Diego via gem5-dev [gem5-dev@gem5.org]
>> >> Sent: Tuesday, December 09, 2014 2:09 AM
>> >> To: gem5 Developer List
>> >> Subject: 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 and limitLow) are interchanged and
>> >> several segment descriptor values are wrong too. If these values are
>> >> corrected kvm works again as before.
>> >>
>> >> Adrian
>> >>
>> >> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev
>> escribió:
>> >> > I also faced problem in getting KVM CPU to run in FS mode.  I
>> >> > figured
>> >> that
>> >> > the following changeset causes problems:
>> >> >
>> >> > authorAlexandru Dutu 
>> >> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
>> >> > changeset 10554   fe2e2f06a7c8
>> >> >
>> >> > I saw the hardware reason 0x8021, but did not try to figure
>> >> > what was going on wrong.
>> >> >
>> >> > --
>> >> > Nilay
>> >> >
>> >> > 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 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 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 reason is 0x8021, that
>> >> seems to
>> >> > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in
>> >> > >> linux
>> >> kernel
>> >> > >> source code). When running in SE

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

[Gabe Black via gem5-dev]

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
think the type was being set wrong for one of the segments. Also, the
syscall and sysenter registers (star and friends) require 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 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
> FS working?
>
> Thanks,
> 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:07 PM
> To: gem5 Developer List
> Subject: 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.
> >
> > 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 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
> >> Processors: 1
> >> PANIC: early exception rip 807909a9 error 9 cr2
> >> ff5fd020
> >>
> >> Can please provide a patch with all the modifications that fixed the
> >> issue on your system?
> >>
> >> Thank you,
> >> Alex
> >> 
> >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián Colaso
> >> Diego via gem5-dev [gem5-dev@gem5.org]
> >> Sent: Tuesday, December 09, 2014 2:09 AM
> >> To: gem5 Developer List
> >> Subject: 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 and limitLow) are interchanged and
> >> several segment descriptor values are wrong too. If these values are
> >> corrected kvm works again as before.
> >>
> >> Adrian
> >>
> >> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
> >> > I also faced problem in getting KVM CPU to run in FS mode.  I
> >> > figured
> >> that
> >> > the following changeset causes problems:
> >> >
> >> > authorAlexandru Dutu 
> >> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
> >> > changeset 10554   fe2e2f06a7c8
> >> >
> >> > I saw the hardware reason 0x8021, but did not try to figure
> >> > what was going on wrong.
> >> >
> >> > --
> >> > Nilay
> >> >
> >> > 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 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 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 reason is 0x8021, that
> >> seems to
> >> > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in
> >> > >> linux
> >> kernel
> >> > >> source code). When running in SE mode, we are trying to bring
> >> > >> the
> >> machine
> >> > >> state to full 64bit mode without going through legacy modes. It
> >> might be
> >> > >> that Intel machines have a different way of going to 64bit mode
> >> > >> than
> >> AMD
> >> > >> machines (different CR4, different way of enabling 64bit mode
> >> > >> page
> >> tables
> >> > >> etc.). I remember dealing with these issue for AMD platfor

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

[Dutu, Alexandru via gem5-dev]

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 FS working?

Thanks,
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:07 PM
To: gem5 Developer List
Subject: 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.
>
> 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 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
>> Processors: 1
>> PANIC: early exception rip 807909a9 error 9 cr2 
>> ff5fd020
>>
>> Can please provide a patch with all the modifications that fixed the 
>> issue on your system?
>>
>> Thank you,
>> Alex
>> 
>> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián Colaso 
>> Diego via gem5-dev [gem5-dev@gem5.org]
>> Sent: Tuesday, December 09, 2014 2:09 AM
>> To: gem5 Developer List
>> Subject: 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 and limitLow) are interchanged and 
>> several segment descriptor values are wrong too. If these values are 
>> corrected kvm works again as before.
>>
>> Adrian
>>
>> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
>> > I also faced problem in getting KVM CPU to run in FS mode.  I 
>> > figured
>> that
>> > the following changeset causes problems:
>> >
>> > authorAlexandru Dutu 
>> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
>> > changeset 10554   fe2e2f06a7c8
>> >
>> > I saw the hardware reason 0x8021, but did not try to figure 
>> > what was going on wrong.
>> >
>> > --
>> > Nilay
>> >
>> > 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 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 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 reason is 0x8021, that
>> seems to
>> > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in 
>> > >> linux
>> kernel
>> > >> source code). When running in SE mode, we are trying to bring 
>> > >> the
>> machine
>> > >> state to full 64bit mode without going through legacy modes. It
>> might be
>> > >> that Intel machines have a different way of going to 64bit mode 
>> > >> than
>> AMD
>> > >> machines (different CR4, different way of enabling 64bit mode 
>> > >> page
>> tables
>> > >> etc.). I remember dealing with these issue for AMD platforms by 
>> > >> going through System Programming manual and making sure gem5 
>> > >> gets all the
>> bits
>> > >> right as there is not much the KVM kernel model will tell about 
>> > >> the
>> cause
>> > >> of failure.
>> > >>
>> > >> Best regards,
>> > >> Alex
>> > >> 
>> > >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe 
>> > >> Black
>> via
>> > >> gem5-dev [gem5-dev@gem5.org]
>> > >> Sent: Monday, December 08, 2014 7:08 PM
>> > >> To: gem5 Developer List
>> > >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
>> > >>
>> > >> I'm not an expert either, but I did have problems running KVM in 
>> > >> SE
>> mode on
>> > >> an Intel CPU. I didn't look into it that much, but I think 
>> > >> things
>> failed in
>> > >> the kernel somew

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

[Gabe Black via gem5-dev]

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.
>
> 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 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
>> Processors: 1
>> PANIC: early exception rip 807909a9 error 9 cr2 ff5fd020
>>
>> Can please provide a patch with all the modifications that fixed the
>> issue on your system?
>>
>> Thank you,
>> Alex
>> 
>> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián Colaso
>> Diego via gem5-dev [gem5-dev@gem5.org]
>> Sent: Tuesday, December 09, 2014 2:09 AM
>> To: gem5 Developer List
>> Subject: 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 and limitLow) are interchanged and
>> several segment descriptor values are wrong too. If these
>> values are corrected kvm works again as before.
>>
>> Adrian
>>
>> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
>> > I also faced problem in getting KVM CPU to run in FS mode.  I figured
>> that
>> > the following changeset causes problems:
>> >
>> > authorAlexandru Dutu 
>> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
>> > changeset 10554   fe2e2f06a7c8
>> >
>> > I saw the hardware reason 0x8021, but did not try to figure what was
>> > going on wrong.
>> >
>> > --
>> > Nilay
>> >
>> > 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 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 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 reason is 0x8021, that
>> seems to
>> > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in linux
>> kernel
>> > >> source code). When running in SE mode, we are trying to bring the
>> machine
>> > >> state to full 64bit mode without going through legacy modes. It
>> might be
>> > >> that Intel machines have a different way of going to 64bit mode than
>> AMD
>> > >> machines (different CR4, different way of enabling 64bit mode page
>> tables
>> > >> etc.). I remember dealing with these issue for AMD platforms by going
>> > >> through System Programming manual and making sure gem5 gets all the
>> bits
>> > >> right as there is not much the KVM kernel model will tell about the
>> cause
>> > >> of failure.
>> > >>
>> > >> Best regards,
>> > >> Alex
>> > >> 
>> > >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe Black
>> via
>> > >> gem5-dev [gem5-dev@gem5.org]
>> > >> Sent: Monday, December 08, 2014 7:08 PM
>> > >> To: gem5 Developer List
>> > >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
>> > >>
>> > >> I'm not an expert either, but I did have problems running KVM in SE
>> mode on
>> > >> an Intel CPU. I didn't look into it that much, but I think things
>> failed in
>> > >> the kernel somewhere. What might be happening is that the different
>> vendors
>> > >> hardware virtualization mechanisms are more or less picky about
>> various
>> > >> things. Something might be set up incorrectly, and one
>> implementation gets
>> > >> more upset about it than the other. I believe there are tools which
>> will
>> > >> help you determine whether your VM state is legal. Perhaps Andreas
>> can tell
>> > >> you more about those?
>> > >>
>> > >> Gabe
>> > >>
>> > >> On Mon, Dec 8, 2014 at 4:29 PM, mike upton via gem5-dev <
>> gem5-dev@gem5.org
>> > >>>
>> > >> wrote:
>> > >>
>> > >>> I have verified that x86 kvm works fine on AMD platforms, but fails
>> on
>> > >>> Intel platforms.

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

[Gabe Black via gem5-dev]

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 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
> Processors: 1
> PANIC: early exception rip 807909a9 error 9 cr2 ff5fd020
>
> Can please provide a patch with all the modifications that fixed the issue
> on your system?
>
> Thank you,
> Alex
> 
> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián Colaso
> Diego via gem5-dev [gem5-dev@gem5.org]
> Sent: Tuesday, December 09, 2014 2:09 AM
> To: gem5 Developer List
> Subject: 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 and limitLow) are interchanged and
> several segment descriptor values are wrong too. If these
> values are corrected kvm works again as before.
>
> Adrian
>
> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
> > I also faced problem in getting KVM CPU to run in FS mode.  I figured
> that
> > the following changeset causes problems:
> >
> > authorAlexandru Dutu 
> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
> > changeset 10554   fe2e2f06a7c8
> >
> > I saw the hardware reason 0x8021, but did not try to figure what was
> > going on wrong.
> >
> > --
> > Nilay
> >
> > 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 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 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 reason is 0x8021, that seems
> to
> > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in linux
> kernel
> > >> source code). When running in SE mode, we are trying to bring the
> machine
> > >> state to full 64bit mode without going through legacy modes. It might
> be
> > >> that Intel machines have a different way of going to 64bit mode than
> AMD
> > >> machines (different CR4, different way of enabling 64bit mode page
> tables
> > >> etc.). I remember dealing with these issue for AMD platforms by going
> > >> through System Programming manual and making sure gem5 gets all the
> bits
> > >> right as there is not much the KVM kernel model will tell about the
> cause
> > >> of failure.
> > >>
> > >> Best regards,
> > >> Alex
> > >> 
> > >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe Black
> via
> > >> gem5-dev [gem5-dev@gem5.org]
> > >> Sent: Monday, December 08, 2014 7:08 PM
> > >> To: gem5 Developer List
> > >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> > >>
> > >> I'm not an expert either, but I did have problems running KVM in SE
> mode on
> > >> an Intel CPU. I didn't look into it that much, but I think things
> failed in
> > >> the kernel somewhere. What might be happening is that the different
> vendors
> > >> hardware virtualization mechanisms are more or less picky about
> various
> > >> things. Something might be set up incorrectly, and one implementation
> gets
> > >> more upset about it than the other. I believe there are tools which
> will
> > >> help you determine whether your VM state is legal. Perhaps Andreas
> can tell
> > >> you more about those?
> > >>
> > >> Gabe
> > >>
> > >> On Mon, Dec 8, 2014 at 4:29 PM, mike upton via gem5-dev <
> gem5-dev@gem5.org
> > >>>
> > >> wrote:
> > >>
> > >>> I have verified that x86 kvm works fine on AMD platforms, but fails
> on
> > >>> Intel platforms.
> > >>>
> > >>> Any hints about how to narrow down the cause (other than diving into
> gdb,
> > >>> which I will do).
> > >>>
> > >>> I am not an expert in KVM or how gem5 hooks up to libkvm.
> > >>> ___
> > >>> gem5-dev mailin

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

[Brad Beckmann via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2549/#review5657
---



src/mem/ruby/system/RubyPort.cc


Why are you removing these lines?  Is the tester now aware when the port is 
blocked and does it handle retries correctly?  I would prefer if it did not.  
We want the tester to be as aggressive as possible.


- Brad Beckmann


On Dec. 9, 2014, 3:15 p.m., Nilay Vaish wrote:
> 
> ---
> 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.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10602:d3bb9d95bf76
> ---
> ruby: ruby port: do not check for blocked ports
> RubyPort used to maintain a list of blocked ports which are sent retries when
> the port becomes unblocked.  This is unnecessary since RubyPort's port 
> definitions
> inherit from QueuedPort.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/system/RubyPort.hh 6efb37480d87 
>   src/mem/ruby/system/RubyPort.cc 6efb37480d87 
> 
> Diff: http://reviews.gem5.org/r/2549/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay Vaish
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Dutu, Alexandru via gem5-dev]

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
Processors: 1
PANIC: early exception rip 807909a9 error 9 cr2 ff5fd020

Can please provide a patch with all the modifications that fixed the issue on 
your system?

Thank you,
Alex

From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián Colaso Diego via 
gem5-dev [gem5-dev@gem5.org]
Sent: Tuesday, December 09, 2014 2:09 AM
To: gem5 Developer List
Subject: 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 and limitLow) are interchanged and
several segment descriptor values are wrong too. If these
values are corrected kvm works again as before.

Adrian

El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
> I also faced problem in getting KVM CPU to run in FS mode.  I figured that
> the following changeset causes problems:
>
> authorAlexandru Dutu 
>   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
> changeset 10554   fe2e2f06a7c8
>
> I saw the hardware reason 0x8021, but did not try to figure what was
> going on wrong.
>
> --
> Nilay
>
> 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 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 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 reason is 0x8021, that seems to
> >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in linux kernel
> >> source code). When running in SE mode, we are trying to bring the machine
> >> state to full 64bit mode without going through legacy modes. It might be
> >> that Intel machines have a different way of going to 64bit mode than AMD
> >> machines (different CR4, different way of enabling 64bit mode page tables
> >> etc.). I remember dealing with these issue for AMD platforms by going
> >> through System Programming manual and making sure gem5 gets all the bits
> >> right as there is not much the KVM kernel model will tell about the cause
> >> of failure.
> >>
> >> Best regards,
> >> Alex
> >> 
> >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe Black via
> >> gem5-dev [gem5-dev@gem5.org]
> >> Sent: Monday, December 08, 2014 7:08 PM
> >> To: gem5 Developer List
> >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> >>
> >> I'm not an expert either, but I did have problems running KVM in SE mode on
> >> an Intel CPU. I didn't look into it that much, but I think things failed in
> >> the kernel somewhere. What might be happening is that the different vendors
> >> hardware virtualization mechanisms are more or less picky about various
> >> things. Something might be set up incorrectly, and one implementation gets
> >> more upset about it than the other. I believe there are tools which will
> >> help you determine whether your VM state is legal. Perhaps Andreas can tell
> >> you more about those?
> >>
> >> Gabe
> >>
> >> On Mon, Dec 8, 2014 at 4:29 PM, mike upton via gem5-dev  >>>
> >> wrote:
> >>
> >>> I have verified that x86 kvm works fine on AMD platforms, but fails on
> >>> Intel platforms.
> >>>
> >>> Any hints about how to narrow down the cause (other than diving into gdb,
> >>> which I will do).
> >>>
> >>> I am not an expert in KVM or how gem5 hooks up to libkvm.
> >>> ___
> >>> gem5-dev mailing list
> >>> gem5-dev@gem5.org
> >>> http://m5sim.org/mailman/listinfo/gem5-dev
> >>>
> >> ___
> >> gem5-dev mailing list
> >> gem5-dev@gem5.org
> >> http://m5sim.org/mailman/listinfo/gem5-dev
> >> ___
> >> gem5-dev mailing list
> >> gem5-dev@gem5.org
> >> http://m5sim.org/mailman/listinfo/gem5-dev
> >>
> > ___
> > gem5-dev mailing list
> > gem5-dev@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev

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

[Gabe Black via gem5-dev]

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 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 at 0xFEC0.
> Setting APIC routing to flat
> Processors: 1
> PANIC: early exception rip 807909a9 error 9 cr2 ff5fd020
>
> Can you please provide a patch with all the modifications that fixed the
> issue on your system?
>
> Thank you,
> Alex
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike upton
> via gem5-dev
> Sent: Tuesday, December 09, 2014 11:52 AM
> To: gem5 Developer List
> Subject: 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 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 and limitLow) are interchanged and
> > several segment descriptor values are wrong too. If these values are
> > corrected kvm works again as before.
> >
> > Adrian
> >
> > El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
> > > I also faced problem in getting KVM CPU to run in FS mode.  I
> > > figured
> > that
> > > the following changeset causes problems:
> > >
> > > authorAlexandru Dutu 
> > >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
> > > changeset 10554   fe2e2f06a7c8
> > >
> > > I saw the hardware reason 0x8021, but did not try to figure what
> > > was going on wrong.
> > >
> > > --
> > > Nilay
> > >
> > > 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 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 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 reason is 0x8021, that
> > > >> seems
> > to
> > > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in linux
> > kernel
> > > >> source code). When running in SE mode, we are trying to bring the
> > machine
> > > >> state to full 64bit mode without going through legacy modes. It
> > > >> might
> > be
> > > >> that Intel machines have a different way of going to 64bit mode
> > > >> than
> > AMD
> > > >> machines (different CR4, different way of enabling 64bit mode
> > > >> page
> > tables
> > > >> etc.). I remember dealing with these issue for AMD platforms by
> > > >> going through System Programming manual and making sure gem5 gets
> > > >> all the
> > bits
> > > >> right as there is not much the KVM kernel model will tell about
> > > >> the
> > cause
> > > >> of failure.
> > > >>
> > > >> Best regards,
> > > >> Alex
> > > >> 
> > > >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe
> > > >> Black
> > via
> > > >> gem5-dev [gem5-dev@gem5.org]
> > > >> Sent: Monday, December 08, 2014 7:08 PM
> > > >> To: gem5 Developer List
> > > >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> > > >>
> > > >> I'm not an expert either, but I did have problems running KVM in
> > > >> SE
> > mode on
> > > >> an Intel CPU. I didn't look into it that much, but I think things
> > failed in
> > > >> the kernel somewhere. What might be happening is that the
> > > >> different
> > vendors
> > > >> hardware virtualization mechanisms are more or less picky about
> > various
> > > >> things. Something might be set up incorrectly, and one
> > > >> implementation
> > gets
> > > >> more upset about it than the other. I believe there are tools
> > > >> which
> > will
> > > >> help you determine whether your VM state is legal. Perhaps
> > > >> Andreas
> > can tell
> > > >> you more about those?
> > > >>
> > > >> Gabe
> > > >>
> > > >> On Mon, Dec 8, 2014 at 4:2

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

[Dutu, Alexandru via gem5-dev]

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 at 0xFEC0.
Setting APIC routing to flat
Processors: 1
PANIC: early exception rip 807909a9 error 9 cr2 ff5fd020

Can you please provide a patch with all the modifications that fixed the issue 
on your system?

Thank you,
Alex

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike upton via 
gem5-dev
Sent: Tuesday, December 09, 2014 11:52 AM
To: gem5 Developer List
Subject: 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 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 and limitLow) are interchanged and 
> several segment descriptor values are wrong too. If these values are 
> corrected kvm works again as before.
>
> Adrian
>
> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
> > I also faced problem in getting KVM CPU to run in FS mode.  I 
> > figured
> that
> > the following changeset causes problems:
> >
> > authorAlexandru Dutu 
> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
> > changeset 10554   fe2e2f06a7c8
> >
> > I saw the hardware reason 0x8021, but did not try to figure what 
> > was going on wrong.
> >
> > --
> > Nilay
> >
> > 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 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 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 reason is 0x8021, that 
> > >> seems
> to
> > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in linux
> kernel
> > >> source code). When running in SE mode, we are trying to bring the
> machine
> > >> state to full 64bit mode without going through legacy modes. It 
> > >> might
> be
> > >> that Intel machines have a different way of going to 64bit mode 
> > >> than
> AMD
> > >> machines (different CR4, different way of enabling 64bit mode 
> > >> page
> tables
> > >> etc.). I remember dealing with these issue for AMD platforms by 
> > >> going through System Programming manual and making sure gem5 gets 
> > >> all the
> bits
> > >> right as there is not much the KVM kernel model will tell about 
> > >> the
> cause
> > >> of failure.
> > >>
> > >> Best regards,
> > >> Alex
> > >> 
> > >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe 
> > >> Black
> via
> > >> gem5-dev [gem5-dev@gem5.org]
> > >> Sent: Monday, December 08, 2014 7:08 PM
> > >> To: gem5 Developer List
> > >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> > >>
> > >> I'm not an expert either, but I did have problems running KVM in 
> > >> SE
> mode on
> > >> an Intel CPU. I didn't look into it that much, but I think things
> failed in
> > >> the kernel somewhere. What might be happening is that the 
> > >> different
> vendors
> > >> hardware virtualization mechanisms are more or less picky about
> various
> > >> things. Something might be set up incorrectly, and one 
> > >> implementation
> gets
> > >> more upset about it than the other. I believe there are tools 
> > >> which
> will
> > >> help you determine whether your VM state is legal. Perhaps 
> > >> Andreas
> can tell
> > >> you more about those?
> > >>
> > >> Gabe
> > >>
> > >> On Mon, Dec 8, 2014 at 4:29 PM, mike upton via gem5-dev <
> gem5-dev@gem5.org
> > >>>
> > >> wrote:
> > >>
> > >>> I have verified that x86 kvm works fine on AMD platforms, but 
> > >>> fails
> on
> > >>> Intel platforms.
> > >>>
> > >>> Any hints about how to narrow down the cause (other than diving 
> > >>> into
> gdb,
> > >>> which I will do).
> > >>>
> > >>> I am not an expert in KVM or how gem5 hooks up to libkvm.
> > >>

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

[mike upton via gem5-dev]

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 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 and limitLow) are interchanged and
> several segment descriptor values are wrong too. If these
> values are corrected kvm works again as before.
>
> Adrian
>
> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
> > I also faced problem in getting KVM CPU to run in FS mode.  I figured
> that
> > the following changeset causes problems:
> >
> > authorAlexandru Dutu 
> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
> > changeset 10554   fe2e2f06a7c8
> >
> > I saw the hardware reason 0x8021, but did not try to figure what was
> > going on wrong.
> >
> > --
> > Nilay
> >
> > 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 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 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 reason is 0x8021, that seems
> to
> > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in linux
> kernel
> > >> source code). When running in SE mode, we are trying to bring the
> machine
> > >> state to full 64bit mode without going through legacy modes. It might
> be
> > >> that Intel machines have a different way of going to 64bit mode than
> AMD
> > >> machines (different CR4, different way of enabling 64bit mode page
> tables
> > >> etc.). I remember dealing with these issue for AMD platforms by going
> > >> through System Programming manual and making sure gem5 gets all the
> bits
> > >> right as there is not much the KVM kernel model will tell about the
> cause
> > >> of failure.
> > >>
> > >> Best regards,
> > >> Alex
> > >> 
> > >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe Black
> via
> > >> gem5-dev [gem5-dev@gem5.org]
> > >> Sent: Monday, December 08, 2014 7:08 PM
> > >> To: gem5 Developer List
> > >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> > >>
> > >> I'm not an expert either, but I did have problems running KVM in SE
> mode on
> > >> an Intel CPU. I didn't look into it that much, but I think things
> failed in
> > >> the kernel somewhere. What might be happening is that the different
> vendors
> > >> hardware virtualization mechanisms are more or less picky about
> various
> > >> things. Something might be set up incorrectly, and one implementation
> gets
> > >> more upset about it than the other. I believe there are tools which
> will
> > >> help you determine whether your VM state is legal. Perhaps Andreas
> can tell
> > >> you more about those?
> > >>
> > >> Gabe
> > >>
> > >> On Mon, Dec 8, 2014 at 4:29 PM, mike upton via gem5-dev <
> gem5-dev@gem5.org
> > >>>
> > >> wrote:
> > >>
> > >>> I have verified that x86 kvm works fine on AMD platforms, but fails
> on
> > >>> Intel platforms.
> > >>>
> > >>> Any hints about how to narrow down the cause (other than diving into
> gdb,
> > >>> which I will do).
> > >>>
> > >>> I am not an expert in KVM or how gem5 hooks up to libkvm.
> > >>> ___
> > >>> gem5-dev mailing list
> > >>> gem5-dev@gem5.org
> > >>> http://m5sim.org/mailman/listinfo/gem5-dev
> > >>>
> > >> ___
> > >> gem5-dev mailing list
> > >> gem5-dev@gem5.org
> > >> http://m5sim.org/mailman/listinfo/gem5-dev
> > >> ___
> > >> gem5-dev mailing list
> > >> gem5-dev@gem5.org
> > >> http://m5sim.org/mailman/listinfo/gem5-dev
> > >>
> > > ___
> > > gem5-dev mailing list
> > > gem5-dev@gem5.org
> > > http://m5sim.org/mailman/listinfo/gem5-dev
> > >
> > ___
> > gem5-dev mailing list
> > gem5-dev@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev
>
>
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman

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

[Jason Power via gem5-dev]

---
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 Vaish wrote:
> 
> ---
> 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.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10602:d3bb9d95bf76
> ---
> ruby: ruby port: do not check for blocked ports
> RubyPort used to maintain a list of blocked ports which are sent retries when
> the port becomes unblocked.  This is unnecessary since RubyPort's port 
> definitions
> inherit from QueuedPort.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/system/RubyPort.hh 6efb37480d87 
>   src/mem/ruby/system/RubyPort.cc 6efb37480d87 
> 
> Diff: http://reviews.gem5.org/r/2549/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay Vaish
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Andreas Hansson via gem5-dev]

---
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 Vaish wrote:
> 
> ---
> 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.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10602:d3bb9d95bf76
> ---
> ruby: ruby port: do not check for blocked ports
> RubyPort used to maintain a list of blocked ports which are sent retries when
> the port becomes unblocked.  This is unnecessary since RubyPort's port 
> definitions
> inherit from QueuedPort.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/system/RubyPort.hh 6efb37480d87 
>   src/mem/ruby/system/RubyPort.cc 6efb37480d87 
> 
> Diff: http://reviews.gem5.org/r/2549/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay Vaish
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Nilay Vaish via gem5-dev]

---
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)
-

ruby: ruby port: do not check for blocked ports


Repository: gem5


Description (updated)
---

Changeset 10602:d3bb9d95bf76
---
ruby: ruby port: do not check for blocked ports
RubyPort used to maintain a list of blocked ports which are sent retries when
the port becomes unblocked.  This is unnecessary since RubyPort's port 
definitions
inherit from QueuedPort.


Diffs (updated)
-

  src/mem/ruby/system/RubyPort.hh 6efb37480d87 
  src/mem/ruby/system/RubyPort.cc 6efb37480d87 

Diff: http://reviews.gem5.org/r/2549/diff/


Testing
---


Thanks,

Nilay Vaish

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Cron Daemon via gem5-dev]

* 
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/linux/rubytest-ruby-MOESI_hammer
 passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby 
passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level
 passed.
* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby 
passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level
 passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/inorder-timing passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter 
passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/inorder-timing passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby 
passed.
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-timing passed.
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple

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

[Adrián Colaso Diego via gem5-dev]

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 and limitLow) are interchanged and
several segment descriptor values are wrong too. If these
values are corrected kvm works again as before.

Adrian

El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
> I also faced problem in getting KVM CPU to run in FS mode.  I figured that 
> the following changeset causes problems:
> 
> authorAlexandru Dutu 
>   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
> changeset 10554   fe2e2f06a7c8
> 
> I saw the hardware reason 0x8021, but did not try to figure what was 
> going on wrong.
> 
> --
> Nilay
> 
> 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 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 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 reason is 0x8021, that seems to
> >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in linux kernel
> >> source code). When running in SE mode, we are trying to bring the machine
> >> state to full 64bit mode without going through legacy modes. It might be
> >> that Intel machines have a different way of going to 64bit mode than AMD
> >> machines (different CR4, different way of enabling 64bit mode page tables
> >> etc.). I remember dealing with these issue for AMD platforms by going
> >> through System Programming manual and making sure gem5 gets all the bits
> >> right as there is not much the KVM kernel model will tell about the cause
> >> of failure.
> >>
> >> Best regards,
> >> Alex
> >> 
> >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe Black via
> >> gem5-dev [gem5-dev@gem5.org]
> >> Sent: Monday, December 08, 2014 7:08 PM
> >> To: gem5 Developer List
> >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> >>
> >> I'm not an expert either, but I did have problems running KVM in SE mode on
> >> an Intel CPU. I didn't look into it that much, but I think things failed in
> >> the kernel somewhere. What might be happening is that the different vendors
> >> hardware virtualization mechanisms are more or less picky about various
> >> things. Something might be set up incorrectly, and one implementation gets
> >> more upset about it than the other. I believe there are tools which will
> >> help you determine whether your VM state is legal. Perhaps Andreas can tell
> >> you more about those?
> >>
> >> Gabe
> >>
> >> On Mon, Dec 8, 2014 at 4:29 PM, mike upton via gem5-dev  >>>
> >> wrote:
> >>
> >>> I have verified that x86 kvm works fine on AMD platforms, but fails on
> >>> Intel platforms.
> >>>
> >>> Any hints about how to narrow down the cause (other than diving into gdb,
> >>> which I will do).
> >>>
> >>> I am not an expert in KVM or how gem5 hooks up to libkvm.
> >>> ___
> >>> gem5-dev mailing list
> >>> gem5-dev@gem5.org
> >>> http://m5sim.org/mailman/listinfo/gem5-dev
> >>>
> >> ___
> >> gem5-dev mailing list
> >> gem5-dev@gem5.org
> >> http://m5sim.org/mailman/listinfo/gem5-dev
> >> ___
> >> gem5-dev mailing list
> >> gem5-dev@gem5.org
> >> http://m5sim.org/mailman/listinfo/gem5-dev
> >>
> > ___
> > gem5-dev mailing list
> > gem5-dev@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev
> >
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev


___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev