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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 B4D4BC433ED for ; Fri, 23 Apr 2021 15:59:46 +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 0A68460C40 for ; Fri, 23 Apr 2021 15:59:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A68460C40 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:57568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZyDX-0005Vf-7h for qemu-devel@archiver.kernel.org; Fri, 23 Apr 2021 11:59:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51052) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZyBz-0004tM-LA for qemu-devel@nongnu.org; Fri, 23 Apr 2021 11:58:08 -0400 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:47041) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lZyBx-0002l4-Ss for qemu-devel@nongnu.org; Fri, 23 Apr 2021 11:58:07 -0400 Received: by mail-wm1-x334.google.com with SMTP id k4-20020a7bc4040000b02901331d89fb83so1483904wmi.5 for ; Fri, 23 Apr 2021 08:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=d9q/OZZRjlD+J5z0b+Q6nRqKlXdRlLIaorE8Rj3NzMo=; b=YdWJDZzyerRhW4Xm1J5ZAYRESTk/hisHgYpo/LC+KB10KrL1DJ2QVdrWWQ1VcYz6Mm gSTjwt0+9QU8PJV/AFvSp6GbTSRNd51O4/bjw2MoOpuIZwipZ0Idos/2J6rK9fCgoIK7 jZEr0frqNB4tgUg9RxW+E+Dq3BG88lMFgzHvsdQMbPHOEBlaMBqhTtlWef9HmwmeQQtN 7coeNXhgGIl2nSU3PjC+Xzz9TNq3Y+eGrl8omQA48GDc2Hb3c/IvjofD340vSYB5Ffbp 3gDzEVriKtOHxYhHob2lL0Wzv6p+cchCRlnSb4DvZy7mwyd84F8CIthdEvOlHzskd3ef GXKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=d9q/OZZRjlD+J5z0b+Q6nRqKlXdRlLIaorE8Rj3NzMo=; b=QH4l7N7wlEZqFF2tZzrbGCxr8MmZ7Kh1xjQcApgBFZAgvaLMn9t+hOmBug0lRImtBL tH1pkQ8foQaLdX/IhWFlHU53jurvxQ68ZB4e8rdhUa2J0Z07ezC8nbZMv/PVm7bKPHVC sG9jYET33GPHZDywSWzHQv0APqA1yTNGitmPOldfMm7Ahsex0ru3ojf/4wi3FJoeUVxf r/BVmeYKCK7ZAAXg/0AmbLkOGeZu7i8SJviBL933Ati82fzyTW0YM7FFTf/zvmYHR6eK n6wHdV87kFgJIoV4odDekJOttDkfFDVf2kP/EE/s5SDbf+VYIQQBFDPFDwXj5XmC+BHJ J2uA== X-Gm-Message-State: AOAM533eT7QyaNGlf7MfcJvl5QDh8OAwR8PHO61t2sGoi9Wpldi076/N vkAugT7fuLaykB/G4pdqDcTBV5haDkYXoA== X-Google-Smtp-Source: ABdhPJyrqFouJt2mgCsHBa/r9tXubm9DndHwv/oye2N8AqeIyKl9GrMX06eGoNSReiTRP7RMwvvEPg== X-Received: by 2002:a05:600c:3397:: with SMTP id o23mr6159199wmp.26.1619193483427; Fri, 23 Apr 2021 08:58:03 -0700 (PDT) Received: from zen.linaroharston ([51.148.130.216]) by smtp.gmail.com with ESMTPSA id i15sm10076740wru.12.2021.04.23.08.58.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Apr 2021 08:58:02 -0700 (PDT) Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id 29C981FF7E; Fri, 23 Apr 2021 16:58:02 +0100 (BST) References: User-agent: mu4e 1.5.11; emacs 28.0.50 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Min-Yih Hsu Subject: Re: [RFC] tcg plugin: Additional plugin interface Date: Fri, 23 Apr 2021 16:44:49 +0100 In-reply-to: Message-ID: <87a6pp6lit.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=alex.bennee@linaro.org; helo=mail-wm1-x334.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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: , Cc: Aaron Lindsay , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Min-Yih Hsu writes: > Hi Alex and QEMU developers, > > Recently I was working with the TCG plugin. I found that `qemu_plugin_cb_= flags` seems to reserve the functionality to > read / write CPU register state, I'm wondering if you can share some > roadmap or thoughts on this feature? I think reading the CPU register state is certainly on the roadmap, writing registers presents a more philosophical question of if it opens the way to people attempting a GPL bypass via plugins. However reading registers would certainly be a worthwhile addition to the API. > Personally I see reading the CPU register state as (kind of) low-hanging = fruit. The most straightforward way to implement > it will be adding another function that can be called by insn_exec callba= cks to read (v)CPU register values. What do you > think about this? It depends on your definition of low hanging fruit ;-) Yes the implementation would be a simple helper which could be called from a callback - I don't think we need to limit it to just insn_exec. I think the challenge is proving a non-ugly API that works cleanly across all the architectures. I'm not keen on exposing arbitrary gdb register IDs to the plugins. There has been some discussion previously on the list which is probably worth reviewing: Date: Mon, 7 Dec 2020 16:03:24 -0500 From: Aaron Lindsay Subject: Plugin Register Accesses Message-ID: But in short I think we need a new subsystem in QEMU where frontends can register registers (sic) and then provide a common API for various users. This common subsystem would then be the source of data for: - plugins - gdbstub - monitor (info registers) - -d LOG_CPU logging If you are interested in tackling such a project I'm certainly happy to provide pointers and review. > > Thank you > -Min --=20 Alex Benn=C3=A9e