After a very entertaining 3 hours or so of merging your branch into mine, I get the following when running kvmtest on android Created VM Created VCPU Got KVM registers struct Sent back KVM registers struct Issued run command, return value is: c5aec000 I didn't see anything significant in dmesg, what is supposed to show up in there? The above doesn't look right to me, which means either I merged something incorrectly, or something else... Also, besides being the answer to life, the universe and everything, what does storing 42 into guest R0 do? Note I haven't tried to debug this yet, if you guys have a quick answer to the above great, if not then I know where my starting point is:) Brian Andreas Nilsson wrote: > Brian (and other interested parties), > > we have now finished a basic kvmtest application which runs a flat > binary. Do an svn update of android/src/kvmtest > > 1. run make in the kvmtest directory which will create the two binaries: > > kvmtest - Actual test executable > example.bin - Flat binary which calculates the 10th Fibonacci number > and stores it in r2 > > 2. copy kvmtest and example.bin to for example /data on the emulator > > 3. run > $ adb shell /data/kvmtest /data/example.bin > > 4. run > $ adb shell dmesg > > to see the fibonacci number outputted from the swi hook > > 5. To create more binaries simply copy example.s and add the new file > to the Makefile. It is probably possible to do the the exact same > thing for library-independent C source files but we didn't try it yet > and it's also more messy to get some valuable info out of the > execution since you don't control the registers completely. > > We have added two "Brian todos" in arch/arm/kvm/arm.c to indicate > appropriate places to hook in the translation and emulation > respectively. Both of these locations are in C files so no funky asm > calls needed :-) > > We also added code to track the pid of the guest process to be able to > determine which process caused an SWI and act accordingly. It should > all be documented in arm.c > > Please shout if anything is unclear. > > /Andreas > > > > To create more binaries simply copy example.s and add the new file to > the Makefile. > > Jason Nieh wrote: >> I'm stuck in a meeting off campus and will be 15 min late. >> -- >> Jason Nieh http://www.cs.columbia.edu/~nieh >> <http://www.cs.columbia.edu/%7Enieh> >> >> On Mar 30, 2009, at 10:26 PM, Christoffer Dall <cd2436 at columbia.edu >> <mailto:cd2436 at columbia.edu>> wrote: >> >>> Hi. >>> >>> Sorry about this. Andreas and I just discussed this, and we couldn't >>> find a time that was good for the both of us, so I am just gonna >>> meet with you guys at 6:30 and represent Andreas at my best. >>> >>> See you tomorrow, and I will be practicing my Swedish accent in the >>> mean time :) >>> >>> /Christoffer >>> >>> On Mon, Mar 30, 2009 at 10:20 PM, David Albert >>> <davidbalbert at gmail.com <mailto:davidbalbert at gmail.com>> wrote: >>> >>> Should be fine for me. >>> >>> Best, >>> -D >>> >>> >>> On Mar 30, 2009, at 10:20 PM, Brian Smith wrote: >>> >>> Hey guys, >>> No one has confirmed tomorrow yet, I wanted to determine if >>> we are or are not meeting. Like I said below, I can meet >>> anytime >>> after 6:30 pm, is 6:30 pm good for everyone? >>> >>> Brian >>> >>> >>> Brian Smith wrote: >>> >>> Hi all, >>> Tuesdays are fine, I can definitely do 6:30 or later, 6 >>> is a little too early for me (I can't guarantee I will be >>> home from work by then). >>> >>> Regards, >>> Brian >>> >>> Christoffer Dall wrote: >>> >>> >>> >>> On Fri, Mar 27, 2009 at 10:22 AM, Jason Nieh >>> <nieh at cs.columbia.edu <mailto:nieh at cs.columbia.edu> >>> <mailto:nieh at cs.columbia.edu >>> <mailto:nieh at cs.columbia.edu>>> wrote: >>> >>> >>> i suggest we do the following: >>> >>> 1. have separate development branches, one for the >>> trap/emulate work >>> that brian is doing, and one for the get the >>> basic user mode stuff >>> to work that andreas/christoffer are doing. >>> >>> >>> This is already set up. If anyone needs help with >>> practical details, please e-mail me and I shall see >>> what I can do to help. >>> >>> >>> >>> 2. all four of you should have a weekly conference >>> call IN ADDITION >>> to the one that we are having on wednesdays to >>> go over your >>> respective parts and stay in sync. please set >>> up a regular >>> meeting time and let me know when - there should >>> not be a week of >>> "we haven't done anything and therefore want to >>> skip the >>> meeting". major design changes to the main >>> branch should be >>> discussed. monday is probably a good day for >>> this. >>> >>> >>> What times are good for you guys? Tuesdays are better >>> for me, around 5/6pm? >>> >>> >>> >>> 3. when code is known to RUN not just compile, it >>> should be checked >>> into the main branch. if there are merging >>> issues, christoffer >>> has volunteered to take care of merging. >>> >>> >>> Sure, I will take of that. We expect to check in >>> first working stuff tomorrow evening. We are fighting >>> with kernel panics after interrupt vector >>> replacements. More on this later. >>> >>> >>> >>> 4. i suggest we get basically functionality >>> working sooner as opposed >>> to later, and check-in to the main branch >>> smaller parts that are >>> functional (ie RUN correctly) as opposed to >>> waiting. >>> >>> 5. christoffer - please set up a mailing list for >>> the group >>> @lists.cs.columbia.edu >>> <http://lists.cs.columbia.edu> >>> <http://lists.cs.columbia.edu>. i'd >>> like to see all email communication >>> related to the project posted on the mailing >>> list so everyone is >>> aware of the technical issues. please include >>> oren as well. >>> >>> >>> in process... >>> >>> >>> >>> 6. if there are important wiki updates, please >>> also email everyone a >>> pointer to the new content. >>> >>> >>> thanks, >>> >>> -- >>> Jason Nieh http://www.cs.columbia.edu/~nieh >>> <http://www.cs.columbia.edu/%7Enieh> >>> <http://www.cs.columbia.edu/%7Enieh> >>> >>> >>> >>> >>> > >
