And yes, you will want the latest kernel from the last_known_good branch of 
rminnich/linux.

On Saturday, February 13, 2016 at 4:22:28 PM UTC-8, Michael Taufen wrote:
>
> > Looks like this debugging bit slipped into this commit. 
> Got it.
>
> > Checkpatch complained about this - line over 80 chars, with no need for 
> > it.  I know most of this code is going to move around or be removed, so 
> > it'd be nice to fix it eventually. 
>
> I'll have to talk to Ron to see exactly what he was getting at with this 
> comment.
> For now, I just shortened the line so Checkpatch won't complain.
>
> > For a future commit, we're going to need to sort out a better way to do
> > allocations for the guest physical memory, so that we don't need to have 
> > everything in one giant function. 
>
> Agreed, this is on my todo list. I'll probably look at refactoring 
> vmrunkernel.c after I finish
> the floating point stuff. The most trivial upgrade in this case would be 
> to just hide the 
> bump-allocated pointer behind an allocation function.
>
> New pull request:
>
> The following changes since commit 
> ca3efb4056d3c531983821c023ecb7ca6796f6c2:
>
>   mlx4: Enable QP destruction (2016-02-10 18:26:46 -0500)
>
> are available in the git repository at:
>
>   [email protected]:mtaufen/akaros.git updates-from-vmm-akaros
>
> for you to fetch changes up to 6caa97691baa761a1f38c8826d79b0e28d590985:
>
>   Updates from vmm-akaros (2016-02-13 16:11:09 -0800)
>
> ----------------------------------------------------------------
> Michael Taufen (1):
>       Updates from vmm-akaros
>
>  kern/arch/x86/trap.c    |  12 ++--
>  tests/vmm/vmrunkernel.c | 238 
> +++++++++++++++++++++++++++++++++++++++++++++------------------------
>  2 files changed, 162 insertions(+), 88 deletions(-)
>
>
>
>
> On Thursday, February 11, 2016 at 10:19:27 AM UTC-8, Barret Rhoden wrote:
>>
>> Hi - 
>>
>> Minor comments below.  Btw, do I need to be using the latest linux 
>> kernel from [email protected]:rminnich/linux.git for this? 
>>
>>
>> On 2016-02-11 at 00:36 "'Michael Taufen' via Akaros" 
>> <[email protected]> wrote: 
>> > The following changes since commit 
>> > ca3efb4056d3c531983821c023ecb7ca6796f6c2: 
>> > 
>> >   mlx4: Enable QP destruction (2016-02-10 18:26:46 -0500) 
>> > 
>> > are available in the git repository at: 
>> > 
>> >   [email protected]:mtaufen/akaros.git updates-from-vmm-akaros 
>>
>> > From 15c0bfc76465921f0f88d163d99a683fde1302a1 Mon Sep 17 00:00:00 2001 
>> > From: Michael Taufen <[email protected]> 
>> > Date: Wed, 10 Feb 2016 09:37:58 -0800 
>> > Subject: Updates from vmm-akaros 
>>
>> > diff --git a/kern/arch/x86/vmm/intel/vmx.c 
>> b/kern/arch/x86/vmm/intel/vmx.c 
>>
>> > @@ -1,4 +1,4 @@ 
>> > -//#define DEBUG 
>> > +#define DEBUG 
>>
>> Looks like this debugging bit slipped into this commit. 
>>
>>
>> > diff --git a/tests/vmm/vmrunkernel.c b/tests/vmm/vmrunkernel.c 
>>
>> > -/* Kind of sad what a total clusterf the pc world is. By 1999, you 
>> could just scan the hardware 
>> > - * and work it out. But 2005, that was no longer possible. How sad. 
>> > +/* Kind of sad what a total clusterf the pc world is. By 1999, you 
>> could just scan the hardware 
>> > + * and work it out. But 2005, that was no longer possible. How sad. 
>> >   * so we have to fake acpi to make it all work. !@#$!@#$#. 
>> >   * This will be copied to memory at 0xe0000, so the kernel can find 
>> it. 
>> >   */ 
>>
>> Checkpatch complained about this - line over 80 chars, with no need for 
>> it.  I know most of this code is going to move around or be removed, so 
>> it'd be nice to fix it eventually. 
>>
>> > + 
>> > +        /* Allocate memory for, and zero the bootparams 
>> > +         * page before writing to it, or Linux thinks 
>> > +         * we're talking crazy. 
>> > +         */ 
>> > +        a += 4096; 
>> > +        bp = a; 
>> > +        memset(bp, 0, 4096); 
>> > + 
>> > +        /* Set the kernel command line parameters */ 
>> > +        a += 4096; 
>> > +        cmdline = a; 
>> > +        a += 4096; 
>>
>> For a future commit, we're going to need to sort out a better way to do 
>> allocations for the guest physical memory, so that we don't need to have 
>> everything in one giant function. 
>>
>> > +        bp->hdr.cmd_line_ptr = (uintptr_t) cmdline; 
>> > +        sprintf(cmdline, "earlyprintk=vmcall,keep" 
>> > +                             " console=hvc0" 
>> > +                             " virtio_mmio.device=1M@0x100000000:32" 
>> > +                             " nosmp" 
>> > +                             " maxcpus=1" 
>> > +                             " acpi.debug_layer=0x2" 
>> > +                             " acpi.debug_level=0xffffffff" 
>> > +                             " apic=debug" 
>> > +                             " noexec=off" 
>> > +                             " nohlt" 
>> > +                             " init=/bin/sh" 
>> > +                             " lapic=notscdeadline" 
>> > +                             " lapictimerfreq=1000" 
>> > +                             " pit=none"); 
>> > + 
>> > + 
>> > +        /* Put the e820 memory region information in the boot_params 
>> */ 
>> > +        bp->e820_entries = 3; 
>> > +        int e820i = 0; 
>> > +        bp->e820_map[e820i].addr = 0; 
>> > +        bp->e820_map[e820i].size = 16*1048576; 
>> > +        bp->e820_map[e820i++].type = E820_RESERVED; 
>> > + 
>> > +        bp->e820_map[e820i].addr = 16*1048576; 
>>
>> Minor formatting thing: please put spaces around operators.  Checkpatch 
>> doesn't seem to catch these for some reason. 
>>
>> > +        bp->e820_map[e820i].size = 128*1048576; 
>> > +        bp->e820_map[e820i++].type = E820_RAM; 
>> > + 
>> > +        //bp->e820_map[2].addr = 4096*1048576ULL; 
>> > +        //bp->e820_map[2].size = 2*1048576; 
>> > +        //bp->e820_map[2].type = E820_RAM; 
>>
>> Do we need this commented out stuff, or was it just for debugging? 
>>
>> > +        bp->e820_map[e820i].addr = 0xf0000000; 
>> > +        bp->e820_map[e820i].size = 0x10000000; 
>> > +        bp->e820_map[e820i++].type = E820_RESERVED; 
>> > + 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to