Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is from all the non-PCI parts of the spec.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We were activating them with the virtqueues, and that's not allowed.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Linux doesn't generate these, but it's perfectly valid according to
a close reading of the spec.  I opened virtio spec bug VIRTIO-134 to
make this clearer there, too.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

As a demonstration, the lguest launcher is pretty strict, trying to
catch badly behaved drivers.  Document this precisely.

A good implementation would *NOT* crash the guest when these happened!
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

There are some (optional) parts we don't implement, but this quotes all
the device requirements from the spec (csd 03, but it should be the same
across all released versions).
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The next patch will insert many quotes from the virtio 1.0 spec; they
make most sense if we copy the spec.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We were clearing the lower bits when setting the upper bits.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The example launcher doesn't reset the queue_enable like the spec says
we have to.  Plus, we should reset the size in case they negotiated
a different (smaller) one.

This is easy to test by unloading and reloading a virtio module.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This was only used for early console, now we can get rid of it altogether.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This simplifies the early probe.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The VIRTIO_PCI_CAP_PCI_CFG in the PCI virtio 1.0 spec allows access to
the BAR registers without mapping them.  This is a compulsory feature,
and we implement it here.

There are some subtleties involving access widths which we should
note:

4.1.4.7.1 Device Requirements: PCI configuration access capability

...
   Upon detecting driver write access to pci_cfg_data, the device MUST
   execute a write access at offset cap.offset at BAR selected by
   cap.bar using the first cap.length bytes from pci_cfg_data.

   Upon detecting driver read access to pci_cfg_data, the device MUST
   execute a read access of length cap.length at offset cap.offset at
   BAR selected by cap.bar and store the first cap.length bytes in
   pci_cfg_data.

So, for a write, we copy into the pci_cfg_data window, then write from
there out to the BAR.  This works correctly if cap.length != width of
write.  Similarly, for a read, we read into window from the BAR then
read the value from there.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is a magic register which causes a character to be outputted: it can
be used even before the device is configured.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We only support virtio 1.0 now
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The only real change here (other than using the PCI bus) is that we
didn't negotiate VIRTIO_NET_F_MRG_RXBUF before, so the format of the
packet header changed with virtio 1.0; we need TUNSETVNETHDRSZ on the
tun fd to tell it about the extra two bytes.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We remove SCSI support (which was removed for 1.0) and VIRTIO_BLK_F_FLUSH
feature flag (removed too, since it's compulsory for 1.0).

The rest is mainly mechanical.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Otherwise Linux fails to find the bus.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We want to use the local kernel headers, but -I../../include/uapi leads us into
a world of hurt.  Instead we create a dummy include/ dir with symlinks.

If we just use #include "../../include/uapi/linux/virtio_blk.h" we get:

	../../include/uapi/linux/virtio_blk.h:31:32: fatal error: linux/virtio_types.h: No such file or directory
	 #include <linux/virtio_types.h>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

For each device, We need to include the vendor capabilities to demark
where virtio common, notification and ISR regions are (we put them
all in BAR0).

We need to handle the switching of the virtqueues using the accessors.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This handles ioport 0xCF8 and 0xCFC accesses, which are used to
read/write PCI device config space.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We don't do anything with them yet (emulate_mmio_write and
emulate_mmio_read are stubs), but we decode the instructions and
search for the device they're hitting.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is where we point our PCI BARs, so that we can intercept MMIO
accesses.  We tell the kernel about it so any faults in this area are
directed to us.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This lets us implement PCI.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

While hacking on getting I/O out to the lguest launcher, I noticed
that returning 0xFF for the PS/2 keyboard status made it spin for a
while thinking there was a key pending.  Fix this by returning 1
instead of 0xFF.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We copy 7 bytes at eip for userspace's instruction decode; we have to
carefully handle the case where eip is at the end of a page.  We can't
leave this to userspace since kernel has all the page table decode
logic.

The decode logic moves to userspace, basically unchanged.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is preparation for userspace handling MMIO and ioport accesses.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Theoretical debates aside, now it boots.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

dwfl_report_offline() works only when libraries are prelinked.

Replace dwfl_report_offline() with dwfl_report_elf() so we correctly
extract debug info even from libraries that are not prelinked.
Reported-by: NJiri Olsa <jolsa@redhat.com>
Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Tested-by: NJiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Link: http://lkml.kernel.org/r/20150114221045.GA17703@us.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Currently the symbol structure is allocated with symbol_conf.priv_size
to carry sideband information like annotation, map browser on TUI and
sort-by-name tree node.  So retrieving these information from symbol
needs to care about the details of such placement.

However the annotation code just assumes that the symbol is placed after
the struct annotation.  But actually there's other info between them.
So accessing those struct will lead to an undefined behavior (usually a
crash) after they write their info to the same location.

To reproduce the problem, please follow the steps below:

  1. run perf report (TUI of course) with -v option
  2. open map browser (by pressing right arrow key for any entry)
  3. search any function (by pressing '/' key and input whatever..)
  4. return to the hist browser (by pressing 'q' or left arrow key)
  5. open annotation window for the same entry (by pressing 'a' key)
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1421234288-22758-1-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Perf tool fails to unwind user stack if the event raises in a shared
object. This patch improves tests/dwarf-unwind.c to demonstrate the
problem by utilizing commonly used glibc function "bsearch". If perf is
not statically linked, the testcase will try to unwind a mixed call
trace.

By debugging libunwind I found that there is a bug in unwind-libunwind:
it always passes 0 as segbase to libunwind, cause libunwind unable to
locate debug_frame entry fir first level ip address (I add some more
debugging output into libunwind to make things clear):

               >_Uarm_dwarf_find_debug_frame: start_ip = 10be98, end_ip = 10c2a4
               >_Uarm_dwarf_find_debug_frame: found debug_frame table `/lib/libc-2.18.so': segbase=0x0, len=7, gp=0x0, table_data=0x449388
               >_Uarm_dwarf_search_unwind_table: call lookup:ip = b6cd3bcc, segbase = 0, rel_ip = b6cd3bcc
               >lookup: e->start_ip_offset = bcf18 (rel_ip = b6cd3bcc)
               >lookup: e->start_ip_offset = 6d314 (rel_ip = b6cd3bcc)
               >lookup: e->start_ip_offset = 33d0c (rel_ip = b6cd3bcc)
                ...
               >lookup: e->start_ip_offset = 15d0c (rel_ip = b6cd3bcc)
               >lookup: e->start_ip_offset = 15c40 (rel_ip = b6cd3bcc)
 >_Uarm_dwarf_search_unwind_table: IP b6cd3bcc inside range b6c12000-b6d4c000, but no explicit unwind info found
                >put_rs_cache: unmasking signals/interrupts and releasing lock
               >_Uarm_dwarf_step: returning -10
 >_Uarm_step: dwarf_step()=-10

This patch passes map->start as segbase to dwarf_find_debug_frame(), so
di will be initialized correctly.

In addition, dso and executable are different when setting segbase. This
patch first check whether the elf is executable, and pass segbase only
for shared object.
Signed-off-by: NWang Nan <wangnan0@huawei.com>
Acked-by: NJiri Olsa <jolsa@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1421203007-75799-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

This is due to duplicated unistd inclusion (via uClibc headers + kernel headers)
Also seen on ARM uClibc based tools

   ------- ARC build ---------->8-------------

  CC       util/evlist.o
In file included from
~/arc/k.org/arch/arc/include/uapi/asm/unistd.h:25:0,
                 from util/../perf-sys.h:10,
                 from util/../perf.h:15,
                 from util/event.h:7,
                 from util/event.c:3:
~/arc/k.org/include/uapi/asm-generic/unistd.h:906:0:
warning: "__NR_fcntl64" redefined [enabled by default]
 #define __NR_fcntl64 __NR3264_fcntl
 ^
In file included from
~/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/sys/syscall.h:24:0,
                 from util/../perf-sys.h:6,
   ----------------->8-------------------

   ------- ARM build ---------->8-------------

  CC FPIC  plugin_scsi.o
In file included from util/../perf-sys.h:9:0,
                 from util/../perf.h:15,
                 from util/cache.h:7,
                 from perf.c:12:
~/arc/k.org/arch/arm/include/uapi/asm/unistd.h:28:0:
warning: "__NR_restart_syscall" redefined [enabled by default]
In file included from
~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/syscall.h:25:0,
                 from util/../perf-sys.h:6,
                 from util/../perf.h:15,
                 from util/cache.h:7,
                 from perf.c:12:
~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/sysnum.h:17:0:
note: this is the location of the previous definition
   ----------------->8-------------------
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1421156604-30603-4-git-send-email-vgupta@synopsys.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

   ----------------->8------------------
  CC       bench/sched-pipe.o
In file included from builtin-annotate.c:13:0:
util/cache.h:76:15: warning: redundant redeclaration of 'strlcpy'
[-Wredundant-decls]
 extern size_t strlcpy(char *dest, const char *src, size_t size);
               ^
In file included from util/util.h:55:0,
                 from builtin.h:4,
                 from builtin-annotate.c:8:
~/vineetg/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/string.h:396:15:
note: previous declaration of 'strlcpy' was here
 extern size_t strlcpy(char *__restrict dst, const char *__restrict src,
   ----------------->8------------------
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1421156604-30603-3-git-send-email-vgupta@synopsys.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

ARC Linux uses the no legacy syscalls abi and corresponding uClibc headers
statfs defines f_type to be U32 which causes perf build breakage

http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common-generic/bits/statfs.h

  ----------->8---------------
    CC       fs/fs.o
  fs/fs.c: In function 'fs__valid_mount':
  fs/fs.c:82:24: error: comparison between signed and unsigned integer
  expressions [-Werror=sign-compare]
    else if (st_fs.f_type != magic)
                          ^
  cc1: all warnings being treated as errors
  ----------->8---------------
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Acked-by: NJiri Olsa <jolsa@kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Cody P Schafer <dev@codyps.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Link: http://lkml.kernel.org/r/1420888254-17504-2-git-send-email-vgupta@synopsys.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

We need to use lib/hweight.c for that, just like we do for lib/rbtree.c,
so tools need to link hweight.o. For now do it directly, but we need to
have a tools/lib/lk.a or .so that collects these goodies...
Reported-by: NJan Beulich <JBeulich@suse.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-a1e91dx3apzqw5kbdt7ut21s@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When thread__init_map_groups() fails, a new thread should be removed
from the rbtree since it's gonna be freed.  Also update last match cache
only if the function succeeded.
Reported-by: NDavid Ahern <dsahern@gmail.com>
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NJiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1420763892-15535-1-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When build with 'make ARCH=x86' and dwarf unwind is on, there is a
compiling error:

   CC       /home/wn/perf/arch/x86/util/unwind-libdw.o
   CC       /home/wn/perf/arch/x86/tests/regs_load.o
 arch/x86/tests/regs_load.S: Assembler messages:
 arch/x86/tests/regs_load.S:65: Error: operand type mismatch for `push'
 arch/x86/tests/regs_load.S:72: Error: operand type mismatch for `pop'
 make[1]: *** [/home/wn/perf/arch/x86/tests/regs_load.o] Error 1
 make[1]: INTERNAL: Exiting with 25 jobserver tokens available; should be 24!
 make: *** [all] Error 2
 ...

Which is caused by incorrectly undefine macro HAVE_ARCH_X86_64_SUPPORT.
'config/Makefile.arch' tests __x86_64__ only when 'ARCH=x86_64'.
However, when building x86_64 kernel, ARCH=x86 is valid and commonly
used. Build systems, such as yocto, uses x86_64 compiler with 'ARCH=x86'
to build x86_64 perf, which causes mismatching.

As __LP64__ is defined for x86_64 as well, we can consolidate the
__x86_64__ check to the __LP64__ check and get rid of the IS_X86_64
IMHO.

(This patch is made by Namhyung Kim when replying my v1 patch:

https://lkml.org/lkml/2015/1/7/17

I modified the code to remove dependency on RAW_ARCH:

https://lkml.org/lkml/2015/1/7/865

Namhyung Kim didn't provide his SOB in his original email. I add
mine only for my modification.)
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Signed-off-by: NWang Nan <wangnan0@huawei.com>
Acked-by: NJiri Olsa <jolsa@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1421029255-23039-1-git-send-email-wangnan0@huawei.com
[ Namhyung provided his S-o-B on a followup to this patch thread on lkml ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When it failed to write probe commands to the probe_event file in
debugfs, it needs to propagate the error code properly.  Current code
blindly uses the return value of the write(2) so it always uses
-1 (-EPERM) and it might confuse users.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1420886028-15135-4-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>