Oops, one more thing, added linux_bootparam.h file. New official 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 94877c39adc7ad64d43af4772edc40bf367fc6ab: Updates from vmm-akaros (2016-02-16 10:21:39 -0800) ---------------------------------------------------------------- Michael Taufen (1): Updates from vmm-akaros kern/arch/x86/trap.c | 12 +-- tests/vmm/vmrunkernel.c | 238 ++++++++++++++++++++++++++++++++++++++-------------------- user/vmm/include/linux_bootparam.h | 200 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 362 insertions(+), 88 deletions(-) create mode 100644 user/vmm/include/linux_bootparam.h On Saturday, February 13, 2016 at 4:23:32 PM UTC-8, Michael Taufen wrote: > 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.
