kvm tools: Fix dirent handling on dirent non-friendly filesystems

Some filesystems don't return valid d_type field in dirent
structure (e.g XFS). So we must handle this case properly.

Signed-off-by: Milan Kocian <milon@wq.cz>
Cc: Sasha Levin <levinsasha928@gmail.com>
[ penberg@kernel.org: cleanups ]
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: Don*t generate deps and version file on clean target

This is redundant since we're to remove them right after
being generated.

CC: Ingo Molnar <mingo@kernel.org>
CC: Pekka Enberg <penberg@kernel.org>
CC: Sasha Levin <sasha.levin@oracle.com>
CC: Asias He <asias@redhat.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: Filter out CPU vendor string

Ingo Molnar reports unhandled MSR reads on an AMD machine:

  [1709265.368464] kvm: 25706: cpu6 unhandled rdmsr: 0xc0010048
  [1709265.397161] kvm: 25706: cpu7 unhandled rdmsr: 0xc0010048
  [1709265.425774] kvm: 25706: cpu8 unhandled rdmsr: 0xc0010048

  processor       : 11
  vendor_id       : AuthenticAMD
  cpu family      : 16
  model           : 8
  model name      : AMD Engineering Sample
  stepping        : 0
  cpu MHz         : 2400.000
  cache size      : 512 KB
  physical id     : 1
  siblings        : 6
  core id         : 5
  cpu cores       : 6
  apicid          : 21
  initial apicid  : 13
  fpu             : yes
  fpu_exception   : yes
  cpuid level     : 5
  wp              : yes
  flags           : fpu vme de pse tsc msr pae mce cx8 apic sep
  mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall
  nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc
  rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt
  lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
  3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock
  nrip_save pausefilter
  bogomips        : 4800.01
  TLB size        : 1024 4K pages
  clflush size    : 64
  cache_alignment : 64
  address sizes   : 48 bits physical, 48 bits virtual
  power management: ts ttp tm stc 100mhzsteps hwpstate

and Asias He reports guest not booting on an AMD machine:

  processor       : 0
  vendor_id       : AuthenticAMD
  cpu family      : 21
  model           : 1
  model name      : AMD Opteron(TM) Processor 6274
  stepping        : 2
  microcode       : 0x6000626
  cpu MHz         : 2200.034
  cache size      : 2048 KB
  physical id     : 0
  siblings        : 16
  core id         : 0
  cpu cores       : 8
  apicid          : 32
  initial apicid  : 0
  fpu             : yes
  fpu_exception   : yes
  cpuid level     : 13
  wp              : yes
  flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
  mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
  fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc
  extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1
  sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy
  abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4
  nodeid_msr topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv
  svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists
  pausefilter pfthreshold
  bogomips        : 4400.06
  TLB size        : 1536 4K pages
  clflush size    : 64
  cache_alignment : 64
  address sizes   : 48 bits physical, 48 bits virtual
  power management: ts ttp tm 100mhzsteps hwpstate cpb

If CPU vendor string is not filetered in case of host AMD machine we get
unhandled MSR reads. Thus provide own string and kernel will use generic
CPU init.

Reported-by: Ingo Molnar <mingo@kernel.org>
CC: Sasha Levin <sasha.levin@oracle.com>
Tested-by: Asias He <asias@redhat.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
[ penberg@kernel.org: improve changelog ]
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: add status notification hook to virtio-mmio

Patch e03b449cbddf (kvm tools: add status notification hook for
virtio) converted virtio-net to use a new notification mechanism,
but unfortunately left virtio-mmio behind.

The direct consequence is that both arm and arm64 guests are left
without any form of networking. Not good.

Bring virtio-mmio into this brave new notified world, and feel the
power of being able to ping again.

Acked-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: Asias He <asias.hejun@gmail.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: fix boot of guests with more than 4gb of ram

Commit "kvm tools: virtio: remove hardcoded assumptions
about guest page size" has introduced a bug that prevented
guests with more than 4gb of ram from booting.

The issue is that 'pfn' is a 32bit integer, so when multiplying
it by page size to get the actual page will cause an overflow if
the pfn referred to a memory area above 4gb.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvmtool, seabios: Ignore BIOS POST legacy registers

This makes SeaBIOS limp along all the way to boot menu:

  [penberg@tux kvm]$ ./vm run --firmware /usr/share/seabios/bios.bin
    # lkvm run -k ../../arch/x86/boot/bzImage -m 448 -c 4 --name guest-11658
  Start bios (version 0.6.0)
  Unable to unlock ram - bridge not found
  Ram Size=0x00100000 (0x0000000000000000 high)
  CPU Mhz=13
  Found 1 cpu(s) max supported 1 cpu(s)
  PCI: bus=0 devfn=0x08: vendor_id=0x1af4 device_id=0x1009
  PCI: bus=0 devfn=0x10: vendor_id=0x1af4 device_id=0x1009
  PCI: bus=0 devfn=0x18: vendor_id=0x1af4 device_id=0x1000
  region 0: 0x00000000
  region 1: 0x00000000
  WARNING - Unable to allocate resource at mptable_init:26!
  WARNING - Unable to allocate resource at smbios_init:381!
  Scan for VGA option rom
  WARNING - Timeout at i8042_wait_read:35!
  Found 2 lpt ports
  Found 4 serial ports
  Scan for option roms
  Press F12 for boot menu.

Signed-off-by: Pekka Enberg <penberg@kernel.org>
Merge tag 'v3.10' into kvmtool/next

v3.10 includes virtio SCSI headers that we had a copy of in tools/kvm.

Signed-off-by: Pekka Enberg <penberg@kernel.org>

Conflicts:
	arch/x86/Kconfig
kvm tools: Fix virtio scsi build breakage

Asias writes:

  In include/kvm/virtio-scsi.h, we have

     /* TODO: Remove this when tcm_vhost goes upstream */

  We are redefining VHOST_SCSI_GET_ABI_VERSION and friends because
  tcm_vhost was not upstream at that time. Pekka, I guess we need to
  upgrade kernel version in lkvm repo and drop our own tcm_vhost
  defines.

Ingo writes:

  I can confirm that the patch below fixes the build problem.

Analyzed-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: plug race between uip_init and virtio_net_rx_thread

When fa7226f (kvm tools: init network devices only when the virtio
driver is ready to go) was introduced, a tiny detail was overlooked:

- Initialization of the uip layer is now coming in very late (only
  when the guest driver says it is ready).
- In parallel, the rx thread is created quite early (as soon as the
  queues are allocated).

This cause the rx thread to call uip_rx, which calls uip_buf_get_used,
which starts to use buf_lock mutex/the buf_used_cond, which haven't
been initialized yet. Tears and devastation follow, not to mention a
certain lack of network connectivity for the unsuspecting guest.

The (not so pretty) fix is to split uip_init:
- uip_static_init: initialize the lists, mutexes and conditions,
  called from virtio_net__init_one.
- uip_init: perform the dynamic memory allocations, called from
  notify_status.

This allows the network to be safely initialized.

Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: Fix build of guest init with biarch powerpc compilers

On powerpc we build kvmtool as a 64bit binary. We do that by setting
-m64 in our CFLAGS. For most things we just call $(CC) and it passes
that info onto the linker.

However there is one place where we explicitly call the linker, in the
build of guest/init - and in that case we need to tell the linker to
build 64bit.

We have gotten away with this so far because we have been building with
a 64bit only toolchain. However if you build with a biarch toolchain,
which generally defaults to 32bit, we fail to link.

The fix is to defined LDFLAGS appropriately and pass it to LD.

Tested on powerpc and x86-64.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: powerpc: Implement "system-reboot" RTAS call

On some powerpc systems, reboot is implemented by an RTAS call by the
name of "system-reboot". Currently we don't implement it in kvmtool,
which means instead the guest prints an error and spins.

This is particularly annoying because when the guest kernel panics it
will try to reboot, and end up spinning in the guest.

We can't implement reboot properly, ie. causing a reboot, but it's still
preferable to implement it as halt rather than not implementing it at
all.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: powerpc: Fix init order for xics

xics_init() assumes kvm->nrcpus is already setup.  kvm->nrcpus is setup
in kvm_cpu_init()

Unfortunately xics_init() and kvm_cpu_init() both use base_init().  So
depending on the order randomly determined by the compiler, xics_init()
may initialised see kvm->nrcpus as 0 and not setup any of the icp VCPU
pointers.  This manifests itself later in boot when trying to raise an
IRQ resulting in a null pointer deference/segv.

This moves xics_init() to use dev_base_init() to ensure it happens after
kvm_cpu_init().

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: virtio-mmio: init_ioeventfd should use MMIO for ioeventfd__add_event()

This patch fixes a bug that vtirtio_mmio_init_ioeventfd() passed a wrong
value when it invoked ioeventfd__add_event(). True value of 2nd parameter
indicates the eventfd uses PIO bus which is used by virito-pci, however,
for virtio-mmio, the value should be false.

Signed-off-by: Ying-Shiuan Pan <yspan@itri.org.tw>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: ioeventfd: replace bool parameters to __add_event with flags

A recent fix to virtio MMIO (72a7541ce305 ["kvm tools: virtio-mmio:
init_ioeventfd should use MMIO for ioeventfd__add_event()"]) highlighted
the confusing parameters expected by ioeventfd__add_event.

As per Pekka's suggestion, replace the bool parameters to this function
with a single `flags' argument instead.

Cc: Ying-Shiuan Pan <yingshiuan.pan@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: use #define for maximum number of terminal devices

Though there may be no near-term plans to change the number of terminal
devices in the future, using TERM_MAX_DEVS instead of '4' makes reading
some of the loops over terminal devices clearer.

This patch makes the this substitution where required.

Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: remove periodic tick in favour of a polling thread

Currently the only use of the periodic timer tick in kvmtool is to
handle reading from stdin. Though functional, this periodic tick can be
problematic on slow (eg FPGA) platforms and can cause low interactivity or
even stop the execution from progressing at all.

This patch removes the periodic tick in favour of a dedicated thread blocked
waiting for input from the console. In order to reflect the new behaviour,
the old 'kvm__arch_periodic_tick' function is renamed to 'kvm__arch_read_term'.

In making this change it is necessary to actively flush the emulated serial
console's output buffer after the guest writes to it, as otherwise flushing
only happens with terminal input. Similarly, it is no longer necessary to
flush the buffer when we process input.

Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: stop virtio console doing unnecessary input handling

The asynchronous nature of the virtio input handling (using a job queue)
can result in unnecessary jobs being created if there is some delay in
handing input (the original function to handle the input returns immediately
without the file having been read, and hence poll returns immediately
informing us of data to read).

This patch adds synchronisation to the threads so that we don't start
polling input files again until we've read from the console.

Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
kvm tools: Fix virtio-net iov memcpy

Milan Kocian writes:

  I found the crash in virtio-net-rx thread (I can reproduce it every
  time by 'aptitude update' in VM):

  traps: virtio-net-rx[28933] general protection ip:7f00dda3d107 sp:7f00c58f4de8 error:0 in libc-2.17.so[7f00dd90f000+1a2000]

  gdb backtrace:

  (gdb) bt
  #0  0x00007fb6a548e107 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
  #1  0x000000000041259c in memcpy_toiovecend (iov=0x7fb68d346ea0, iov@entry=0x7fb68d345e90,
      kdata=<optimized out>, kdata@entry=0x7fb68d346e90 "", offset=<optimized out>, len=<optimized out>)
      at util/iovec.c:70
  #2  0x000000000040c66d in virtio_net_rx_thread (p=0x23688a0) at virtio/net.c:117
  #3  0x00007fb6a5b2ee0e in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
  #4  0x00007fb6a54489ed in clone () from /lib/x86_64-linux-gnu/libc.so.6

  I tried to add some printf to diagnose it but it isn't clear to me:

  virtio_net_rx_thread: before memcpy_toiovecend; copied: 0, len: 18890, iovsize: 4096, realiovsize: 4096
  memcpy_toiovecend: offset: 0, len: 4096
  memcpy_toiovecend: iov_len: 4096, len: 4096
  virtio_net_rx_thread: before memcpy_toiovecend; copied: 4096, len: 18890, iovsize: 4096, realiovsize: 4096
  memcpy_toiovecend: offset: 4096, len: 4096
  memcpy_toiovecend: iov_len: 4096, len: 4096
  memcpy_toiovecend: iov_len: 0, len: 4096
  memcpy_toiovecend: iov_len: 0, len: 4096
  .
  N x memcpy_toiovecend: iov_len: 0, len: 4096
  .
  memcpy_toiovecend: iov_len: 0, len: 4096
  memcpy_toiovecend: iov_len: 0, len: 4096
  memcpy_toiovecend: iov_len: 1519143547641528320, len: 4096
  memcpy_toiovecend: iov_len: 193827583623176, len: 4096
  ./runlkvm.sh: line 2: 16090 Segmentation fault

  IMHO problem come when received len size is bigger than maximum of the
  dst iovec (realiovsize). Only iovec size is copied and in the next run
  isn't place to copy the rest of len size.

Asias He writes:

  We should skip copied bytes from the buffer not from the iov itself
  which memcpy_toiovecend does.

Reported-and-tested-by: Milan Kocian <milon@wq.cz>
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@iki.fi>
kvm tools: Don't disable PerfMon if host does not support it

KVM provides of PMU with architectural events, so don't disable
the NMI drivent based performance events when they are available
on the host.

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Asias He <asias.hejun@gmail.com>
Merge tag 'v3.13-rc1' into kvmtool/next

Linux 3.13-rc1

Needed by the ARM folks.

Signed-off-by: Pekka Enberg <penberg@kernel.org>