This is the size that goes in our bootloader count32. But since we will be
copying over the stripped binary anyway, we are probably reading too much data,
for no reason. That should increase boot time a bit.

It currently sits in the middle of the partition table. Move it to a safer
location.

This patch implement the HPET clock driver, that should work as a fallback for
both Xen and KVM, in case the paravirtual clock is not present. This is
unfortunately the situation for all HVM guests running on EC2, so support for
this is paramount. I have tested on KVM forcing the kvmclock to disappear, and
it seems to work all right.

Right now we are doing it right before we parse the MADT, but this is by far
not MADT specific. Other users are planned, and the best way to resolve the
disputes is to have it in a separate constructor

As a cleanup, use wait_for_queue() like virtio-net does.

In an attempt to be clever, we define irq_lock as an object in an anonymous
namespace, so that each translation unit gets its own copy, which is then
optimized away, since the object is never touched.  But the compiler complains
that the object is defined but not used if we include the file but don't
use irq_lock.

Simplify by only declaring the object there, and defining it somewhere else.

They are needed by the JVM when "-javaagent" command line option is
used. After this patch, the jamm memory meter javaagent can be enabled
for Cassandra.

If "-javaagent" option is enabled, the JVM page faults:

  (gdb) bt
  #0  0x000000000033d432 in halt_no_interrupts () at ../../arch/x64/processor.hh:232
  #1  osv::halt () at ../../core/power.cc:20
  #2  0x0000000000214d82 in abort (msg=msg@entry=0x57ea90 "page fault outside application") at ../../runtime.cc:98
  #3  0x00000000002fd4d8 in page_fault (ef=0xffffc0003ffe6008) at ../../core/mmu.cc:943
  #4  <signal handler called>
  #5  0x0000000000373169 in __stpncpy (d=d@entry=0x2000001fe7f0 "dlsym: symbol JVM_begin_signal_setting not found", s=0x0, n=1023)
      at ../../libc/string/stpncpy.c:19
  #6  0x0000000000373ad1 in strncpy (d=0x2000001fe7f0 "dlsym: symbol JVM_begin_signal_setting not found", s=<optimized out>,
      n=<optimized out>) at ../../libc/string/strncpy.c:7
  #7  0x0000100000b0ab67 in os::dll_load (filename=filename@entry=0x2000001febf0 "libinstrument.so",
      ebuf=ebuf@entry=0x2000001fe7f0 "dlsym: symbol JVM_begin_signal_setting not found", ebuflen=ebuflen@entry=1024)
      at /usr/src/debug/java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc19.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1841
  #8  0x0000100000c247eb in lookup_on_load (agent=agent@entry=0xffffc0003976ccc0,
      on_load_symbols=on_load_symbols@entry=0x2000001ffd40, num_symbol_entries=1)
      at /usr/src/debug/java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/thread.cpp:3585
  #9  0x0000100000c2a64f in lookup_agent_on_load (agent=0xffffc0003976ccc0)
      at /usr/src/debug/java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/thread.cpp:3617
  #10 create_vm_init_agents ()
      at /usr/src/debug/java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/thread.cpp:3656
  #11 Threads::create_vm (args=<optimized out>, canTryAgain=canTryAgain@entry=0x2000001ffdb0)
      at /usr/src/debug/java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/thread.cpp:3177
  #12 0x000010000094d7b0 in JNI_CreateJavaVM (vm=0x2000001ffe58, penv=0x2000001ffe60, args=<optimized out>)
      at /usr/src/debug/java-1.7.0-openjdk-1.7.0.25-2.3.12.3.fc19.x86_64/openjdk/hotspot/src/share/vm/prims/jni.cpp:5127
  #13 0x0000100000007b3b in main (argc=<optimized out>, argv=0xffffc0003fff2008) at ../../java/java.cc:73
  #14 0x0000000000208ac8 in run_main (prog=<optimized out>, args=args@entry=0xffffc0003fe9bfa0) at ../../loader.cc:196
  #15 0x0000000000208c68 in do_main_thread (_args=0xffffc0003fe9bfa0) at ../../loader.cc:217
  #16 0x0000000000376d36 in operator() (__closure=0xffffc0003b5e2a00) at ../../libc/pthread.cc:59
  #17 std::_Function_handler<void(), pthread_private::pthread::pthread(void* (*)(void*), void*, sigset_t, const pthread_private::thread_attr*)::__lambda0>::_M_invoke(const std::_Any_data &) (__functor=...) at ../../external/gcc.bin/usr/include/c++/4.8.1/functional:2071
  #18 0x000000000032ed6b in main (this=0xffffc0003a807010) at ../../core/sched.cc:536
  #19 sched::thread_main_c (t=0xffffc0003a807010) at ../../arch/x64/arch-switch.hh:133
  #20 0x000000000031873e in thread_main () at ../../arch/x64/entry.S:101
  Backtrace stopped: frame did not save the PC

This is caused by the JVM expecting dlerror() to return an error string
if dlopen() fails. Fix that up.

Add simple tests for munmap() for file-backed memory maps. This exposes
a limitation in munmap() not writing out MAP_SHARED mappings.

Use the new mmu::msync() function to make sure file-backed memory maps
are written out to disk in munmap().

This adds simple msync() implementation for file-backed memory maps. It
uses the newly added 'file_vma' data structure to write out and fsync
the msync'd region as suggested by Avi Kivity.

Add a new 'file_vma' class that extends 'vma'. This is needed to keep
track of fileref and offset for file-backed VMAs for msync().

Spotted by Pekka.

Different source bases have different error conventions; libc has 0/-1+errno,
while the rest os the source base uses 0/error.

Wrap errors in a class to prevent confusion between the two.

Fixes the following build brekage caused by commit a7d6b269 ("mman: Use
libc_error() in mprotect()"):

../../libc/mman.cc: In function ‘int mprotect(void*, size_t, int)’:
../../libc/mman.cc:36:33: error: ‘libc_error’ was not declared in this scope
         return libc_error(EINVAL);
                                 ^
../../libc/mman.cc:41:33: error: ‘libc_error’ was not declared in this scope
         return libc_error(ENOMEM);
                                 ^
  CXX libc/pipe_buffer.o
  CXX libc/pipe.o
make[1]: *** [libc/mman.o] Error 1

This is used for temporarily dropping a lock in a lexical scope, and
reacquiring it after an exit from the scope (similar to wait_until(mutex),
but without the waiting):

  WITH_LOCK(preempt_lock) {
     // do some stuff
     while (not enough resources) {
        DROP_LOCK(preempt_lock) {
           acquire more resources
        }
        // reload anything that may have changed after DROP_LOCK()
     }
     // do more stuff with the acquired resources
  }

Note that DROP_LOCK() doesn't work will with recursively-taken locks.

We don't want the compiler moving reads after a possible rcu_defer().

In the existing code, each -classpath or -jar paramter replaced the
classpath. This is inconvenient (and unlike the Unix "java" program).
Better just add to the classpath.

For example, now we can run:

  java.so -cp /java/cli.jar -jar /java/web.jar app

  Which runs web.jar's main class, but adds both cli.jar and web.jar
  to the classpath.

Xen has hard requirements on page transfers, and how to feed the grant tables.
The address need to be page aligned, since the pfns and not addresses are used,
and we need to provide at least a full page per buffer, since the hypervisor is
free to fill any data within the page.

To achieve that, the netfront driver will use m_cljget to attach an extended
buffer to the mbuf, from the jumbop zone, since they are page-sized. However,
two problems arise from this:

1) Allocating a page goes through malloc_large. Our implementation of malloc_large
is currently terribly inefficient, and that creates a very heavy contention site.

What I am doing with this patch is to switch our uma implementation to
alloc_page / free_page instead of malloc if the caller of zcreate so specified
(and then of course, specify it for the jumbop cache)

2) The refcount that is attached in the end of the buffer would either extend the
buffer to 4100 bytes - defeating our purpose, or then the buffer would have to be
PAGE_SIZE - 4, to accomodate for the refcount. But since the hypervisor will write
to the whole page, it will eventually overwrite the refcount.

To address that, I am allocating an external reference counter. BSD already
have some infrastructure to do that, and I am taking advantage of this.
However, I have found no way of implementing this in a way in which the
reference count can be easily deduceable from the address of the extended
buffer, without having the supporting mbuf to start from. Any external data
structure such as hashes would probably make freeing way too slow. Thankfully,
uma_find_refcnt and the UMA_ZONE_REFCNT seems to be used mostly in the
setup/destruction phase (the mbuf refcount is used directly, open coded). So my
proposal here is to remove the UMA_ZONE_REFCNT for that zone.

The x2APIC specification says that reading from the X2APIC_ID MSR should return
the physical apic id of the current processor. However, the Xen implementation
(as of 4.2.2) is broken, and reads actually return old style xAPIC id. Even if
they fix it, we still have HVs deployed around that will return the wrong ID.
We can work around this by testing if the returned APIC id is in the form (id
<< 24), since in that case, the first 24 bits will all be zeroed. Then at least
we can get this working everywhere. This may pose a problem if we want to ever
support more than 1 << 24 vCPUs (or if any other HV has some random x2apic
ids), but that is highly unlikely anyway.

As I have described in a previous patch, the Xen hypervisor has a very nasty
bug that causes all of the x2apic msr writes to trigger a GPF. Although the
request proceeds fine despite the GPF, it does bring a problem for all-but-self
style init sequences we are using: after "failing" (succeeding but returning
failure) to deliver the interrupt for the first cpu in the group, xen will
break the loop, therefore not delivering the SIPIs to other cpus in the system
at all. We can work around that by delivering interrupts to each cpu
individually, instead of all-but-self.

Unfortunately, the Xen hypervisor has a very nasty bug (seems to be fixed by a
2013 patch - which means that although it is fixed, a lot of hypervisors will
have it), that causes all of the x2apic msr writes to init related registers
(INIT, SIPI, etc) trigger a GPF. The way to work around this, is to implement a
form of "wrmsr_safe".

I ended up forgetting to remove some kprintfs from device.c that were inserted
during Xen's blkfront development

Now that we can walk through the vma list, add mmap numbers to 'osv
mem':

  (gdb) osv mem
  Total Memory: 4294564864 Bytes
  Mmap Memory:  3278278656 Bytes (76.34%)
  Free Memory:  474492928 Bytes (11.05%)