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
