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 <gabebl...@google.com> 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 <gabebl...@google.com> 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 <gabebl...@google.com> >> 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 <gabebl...@google.com> >> 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 0xFEC00000. >> >>> >> Setting APIC routing to flat >> >>> >> Processors: 1 >> >>> >> PANIC: early exception rip ffffffff807909a9 error 9 cr2 >> >>> >> ffffffffff5fd020 >> >>> >> >> >>> >> 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: >> >>> >> > >> >>> >> > author Alexandru Dutu <alexandru.d...@amd.com> >> >>> >> > Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago) >> >>> >> > changeset 10554 fe2e2f06a7c8 >> >>> >> > >> >>> >> > I saw the hardware reason 0x80000021, 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 0x80000021, >> >>> >> > >> 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/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 >> > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
