From patchwork Sun Feb 12 15:32:48 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vincent Donnefort X-Patchwork-Id: 13137461 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE5FFC05027 for ; Sun, 12 Feb 2023 15:33:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229694AbjBLPdL (ORCPT ); Sun, 12 Feb 2023 10:33:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229520AbjBLPdK (ORCPT ); Sun, 12 Feb 2023 10:33:10 -0500 Received: from mail-wm1-x34a.google.com (mail-wm1-x34a.google.com [IPv6:2a00:1450:4864:20::34a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E6697AA1 for ; Sun, 12 Feb 2023 07:33:06 -0800 (PST) Received: by mail-wm1-x34a.google.com with SMTP id j37-20020a05600c1c2500b003deaf780ab6so5407531wms.4 for ; Sun, 12 Feb 2023 07:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=g1HftSdGyS004IfwkhWh+8a8ByAjMnKCXMzaWQVPz6Y=; b=rHkr2bczWXfZ1Rf97Gh0VrrFih+78H7JeiMK7C/qRIz9lQ1udj+40H1Rh/TFQvsh8P UjPF2XgYEV4WGLGM7+Z27spRJQdJdE51gA1M2u3NWYD3OvkLTKrMh17ymzJ1HdY4f5zd ryWPpriPCJW1oiX+Ee8j35kimhfGgbekolQF9p6SJexZfFg1/oeRZK/Q8vgf0/6hHvvZ IdiQs1JKNCKvGZ50Dgo4UPz1Fap8bguAfbjHIejQMOFNsjiunNdgOf/QtFgp1C9bkpsA 08nAcd4yCu2xJrZhpmqLODzvYbv5H+ab5mPIQR5kSxo4f6D5elGvL9J5tyr5RUJP2DJd /PjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=g1HftSdGyS004IfwkhWh+8a8ByAjMnKCXMzaWQVPz6Y=; b=ZueY6jsCD6sVoEuGxu7TH4E0sFCRg7dBETxbZh5hYk0x/T2FyUGRJ+tSE6RSVo/4ZS OeY/oeUSWvw6mR9BvcR2UBgFGSzFLgjGA8Q9twXj5D4/4dLXz9IsqONUgp3NLNI6lCoG 8vy8easBelGBRROYHh4B+Tshm/hFJt+3m50oTkCEJUaOkisH8vbekbFf6Q5diB/4IswQ 1kdIfguzDgnZOsK7ZdruSN1wjr30jQmJB93p6VEKmKwyUdwKSc/yEH2NafQVIRVlhJyC daj/NlzOR/JnOxC6JwT/i8kzp0gPULLC1rGG1D7bPisuDxe3wH3wFJwrrbTyYRUaeWHW yyOA== X-Gm-Message-State: AO0yUKVmQSzqCWs4lRUKCbJyXuisEckKjcUZYHiBFHa7Cuy3s1cIfkl+ fBJG7+xwXlctiFadopjXhr5aVN6xE4dNeqjE X-Google-Smtp-Source: AK7set/6pZyWnv50IgvomJ7ZKuznSHwum6yJMKBwSx08PcWBdT0+XZf7b1DGjid04ZOAt4M0/f8tesHIK8UASQLr X-Received: from vdonnefort.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:2eea]) (user=vdonnefort job=sendgmr) by 2002:a05:600c:2045:b0:3dc:5ad2:86ed with SMTP id p5-20020a05600c204500b003dc5ad286edmr939213wmg.33.1676215984389; Sun, 12 Feb 2023 07:33:04 -0800 (PST) Date: Sun, 12 Feb 2023 15:32:48 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog Message-ID: <20230212153250.1099136-1-vdonnefort@google.com> Subject: [RFC PATCH 0/2] Introducing trace buffer mapping by user-space From: Vincent Donnefort To: rostedt@goodmis.org, mhiramat@kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: kernel-team@android.com, Vincent Donnefort Precedence: bulk List-ID: X-Mailing-List: linux-trace-kernel@vger.kernel.org Hi all, We (Android folks) have been recently working on bringing tracing to the pKVM hypervisor (more about pKVM? [1] [2]) reusing as much as possible the tracefs support already available in the host. More specifically, sharing the ring_buffer_per_cpu between the kernel and the hypervisor, the later being the writer while the former is only reading. After presenting this endeavour at the tracingsummit, end of last year [3], Steven observed this is a similar problem to another idea he had a while ago: mapping the tracing ring buffers directly into userspace. The tracing ring-buffer can be stored or sent to network without any copy via splice. However the later doesn't allow real time processing of the traces by userspace without a copy, which can only be achieved by letting userspace map directly the ring-buffer. And indeed, in both ideas, we have a ring-buffer, an entity being the writer, the other being a reader and both share the ring buffer pages while having different VA spaces. So here's an RFC bringing userspace mapping of a ring-buffer and if it doesn't cover the pKVM hypervisor it nonetheless brings building blocks that will be reused later. Any feedback very much appreciated. Vincent [1] https://lwn.net/Articles/836693/ [2] https://www.youtube.com/watch?v=9npebeVFbFw [3] https://tracingsummit.org/ts/2022/hypervisortracing/