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
