Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932328AbbFAIIw (ORCPT <rfc822;w@1wt.eu>);
	Mon, 1 Jun 2015 04:08:52 -0400
Received: from dfwrgout.huawei.com ([206.16.17.72]:2484 "EHLO
	dfwrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752645AbbFAIIm (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 1 Jun 2015 04:08:42 -0400
X-Greylist: delayed 419 seconds by postgrey-1.27 at vger.kernel.org; Mon, 01 Jun 2015 04:08:42 EDT
Message-ID: <556BFD61.6090306@huawei.com>
Date: Mon, 1 Jun 2015 14:36:17 +0800
From: "Wangnan (F)" <wangnan0@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Namhyung Kim <namhyung@kernel.org>
CC: <paulus@samba.org>, <a.p.zijlstra@chello.nl>, <mingo@redhat.com>,
        <acme@kernel.org>, <jolsa@kernel.org>, <dsahern@gmail.com>,
        <daniel@iogearbox.net>, <brendan.d.gregg@gmail.com>,
        <masami.hiramatsu.pt@hitachi.com>, <lizefan@huawei.com>,
        <linux-kernel@vger.kernel.org>, <pi3orama@163.com>
Subject: Re: [RFC PATCH v4 17/29] bpf tools: Relocate eBPF programs
References: <1432704004-171454-1-git-send-email-wangnan0@huawei.com> <1432704004-171454-18-git-send-email-wangnan0@huawei.com> <20150601053245.GA22455@danjae>
In-Reply-To: <20150601053245.GA22455@danjae>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.111.66.109]
X-CFilter-Loop: Reflected
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2092
Lines: 55



On 2015/6/1 13:32, Namhyung Kim wrote:
> On Wed, May 27, 2015 at 05:19:52AM +0000, Wang Nan wrote:
>> If an eBPF program access a map, LLVM generates a relocated load
>> instruction. To enable the usage of that map, relocation must be done
>> by replacing original instructions by map loading instructions.
>>
>> Based on relocation description collected during 'opening' phase, this
>> patch replaces the instructions with map loading with correct map fd.
> I think this message is a bit confusing.. How about this?
>
> If an eBPF program accesses a map, LLVM generates a load instruction
> with pseudo map fd.  Since actual map fd can only be known after it

LLVM doesn't generate mapfd. It creates an instruction read a global
structure. something link this:

   ld_64   r1, <MCOperand Expr:(mymap)>
   ...
   call    2

where ld_64 is a (BPF_LD | BPF_IMM | BPF_DW) instruction, src_reg is not
used at all.

What this relocation done is to utilize src_reg, set it to BPF_PSEUDO_MAP_FD
then set the imm field to the fd of the map.

I will update the commit message as follow:

If an eBPF program accesses a map, LLVM generates a load instruction
which loads an absolute address into a register, like this:

   ld_64   r1, <MCOperand Expr:(mymap)>
   ...
   call    2

That ld_64 instruction will be recorded in relocation section.
To enable the usage of that map, relocation must be done by replacing
the immediate value by real map file descriptor so it can be found by
eBPF map functions.

This patch to the relocation work based on information collected by
patch 'bpf tools: Collect relocation sections from SHT_REL sections'.
For each instruction which needs relocation, it inject corresponding
file descriptor to imm field. As a part of protocol, src_reg is set to
BPF_PSEUDO_MAP_FD to notify kernel this is a map loading instruction.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/