From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F35A9C48BD1 for ; Fri, 11 Jun 2021 17:28:39 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AE3F2613CF for ; Fri, 11 Jun 2021 17:28:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE3F2613CF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:48810 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrkxS-0003pd-NR for qemu-devel@archiver.kernel.org; Fri, 11 Jun 2021 13:28:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39432) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrktZ-0008MD-J2 for qemu-devel@nongnu.org; Fri, 11 Jun 2021 13:24:37 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:55574) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrktW-0006FK-H6 for qemu-devel@nongnu.org; Fri, 11 Jun 2021 13:24:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623432274; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=yItp2iXtM7lDtWbu5pbOg/WA643hZbf/CUaS2lpuMq0=; b=aBWE0VHodSjooB5vPC43BQkgq8HxdS2CW2p+863jyu89aWwElPhlPvDImGqYge0KzafJwe OCu+eM3yXBdTx8TjIgTFdN3tHVQ9GLME35BSrl+fRNcsnMu9apwvldiKezImCI/HRcUklo Tu26sRicHl0QJNdpxm2K2+1Kg+eTBKA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-517-DhF_p_cBNu-YbMMSsrdasA-1; Fri, 11 Jun 2021 13:24:30 -0400 X-MC-Unique: DhF_p_cBNu-YbMMSsrdasA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B04291850606; Fri, 11 Jun 2021 17:24:29 +0000 (UTC) Received: from redhat.com (ovpn-115-90.ams2.redhat.com [10.36.115.90]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E181819C84; Fri, 11 Jun 2021 17:24:17 +0000 (UTC) Date: Fri, 11 Jun 2021 18:24:15 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Andrew Melnichenko Subject: Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd. Message-ID: References: <20210609100457.142570-1-andrew@daynix.com> <3da88930-439c-1892-29b4-4977ddbb0b0a@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=216.205.24.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.199, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: "Michael S . Tsirkin" , Jason Wang , qemu-devel@nongnu.org, Markus Armbruster , Yuri Benditovich , Yan Vugenfirer , Eric Blake Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, Jun 11, 2021 at 07:49:21PM +0300, Andrew Melnichenko wrote: > Hi, > > > So I think the series is for unprivileged_bpf disabled. If I'm not > > wrong, I guess the policy is to grant CAP_BPF but do fine grain checks > > via LSM. > > > > The main idea is to run eBPF RSS with qemu without any permission. > Libvirt should handle everything and pass proper eBPF file descriptors. > For current eBPF RSS, CAP_SYS_ADMIN(bypass some limitations) > also required, and in the future may be other permissions. > > I'm not sure this is the best. We have several examples that let libvirt > > to involve. Examples: > > > > 1) create TAP device (and the TUN_SETIFF) > > > > 2) open vhost devices > > > > Technically TAP/vhost not related to a particular qemu emulator. So common > TAP creation should fit any modern qemu. eBPF fds(program and maps) should > suit the interface for current qemu, g.e. some qemu builds may have > different map > structures or their count. It's necessary that the qemu got fds prepared by > the helper > that was built with the qemu. > > I think we need an example on the detail steps for how libvirt is > > expected to use this. > > > > The simplified workflow looks like this: > > 1. Libvirt got "emulator" from domain document. > 2. Libvirt queries for qemu capabilities. > 3. One of the capabilities is "qemu-ebpf-rss-helper" path(if present). > 4. On NIC preparation Libvirt checks for virtio-net + rss configurations. > 5. If required, the "qemu-ebpf-rss-helper" called and fds are received > through unix fd. > 6. Those fds are for eBPF RSS, which passed to child process - qemu. > 7. Qemu launched with virtio-net-pci property "rss" and "ebpf_rss_fds". So this basically works in the same way as the qemu bridge helper, with the extra advantage that we can actually query QEMU for the right helper instead of libvirt hardcoding te helper path. We should make your QMP query command also return the paths for the existing QEMU helpers (bridge helper, and pr helper) too. Anyway, this approach is obviously viable for libvirt, since it matches what we already do for other features. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|