From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F2B81DC994 for ; Thu, 16 Jan 2025 22:53:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737067996; cv=none; b=U0V0AxASPlHlsur2ugb0EiYYsfqkCBfAKd/M2p836wWGYvkCvU/fdFXUUjlyJaRlXk3TPg8f133wK9qPYHGV4aohE15+LCJBnkBGhc5nv7nSzJX5VizfePQQ2I1XlSMXmud3allzP9BKeJ3CnXLQiWHy1xoQLcb6cu0NhJCsYeY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737067996; c=relaxed/simple; bh=M7hrbCFlo1i55ug6XscaT87cRTzYxoSC93gPldebbkw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=H8HmUpF3zwMpP2ykj17NUddm/fUc1ZmamlGdHzr4XlnQRfz8ZZCgiS91Di8WNWl3JODs+jutU9la6DECc0oYqnMEOqLhk/EpW90wsAUPShhH6qo63Q2C6SSAjKe1BvG5Q5Opse2Hx42iB0V+C/Pvd7CJOVSYscgRSAbhsR96Hjc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=cMBMM9Zq; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="cMBMM9Zq" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2162259a5dcso44377255ad.3 for ; Thu, 16 Jan 2025 14:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737067994; x=1737672794; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=YpsNgnSKVlvn4uHhcKm936EMtxOiPoBOMPpxpZBHoq8=; b=cMBMM9Zqd9Dt+B4gFdozhmc65ajV5WV33307e/xfbmhoa0Tw9K4kcAl6QI2cvyfOH7 3FTG0eKiixXqEYkLQRFL2381j/Ui91r2M8ZLUzT/Phm3oTSAUfwUUPMmgAVbHFCIyABs TyMFHPA4xU72j3UPV3wsn45SX/Uqp+/zsIgrdPEg3QfiCiZ8+6h6B60jPabQ0MF89srO njzFjBLDhrLVZ4MiYYiAwrlEf14s4q1bFlCiHos7BCveNz/FCKFIpY6hvPrBhP237QUI FEphIKbRoinn4OhK8HGqoEz2qxo81oDO+CGXhvXo6AngTn002dyJvNhP9jouCpVQUReb w95A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737067994; x=1737672794; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YpsNgnSKVlvn4uHhcKm936EMtxOiPoBOMPpxpZBHoq8=; b=c+oIsUvkwfNxSqLOPiRDAkm4r75RxLkgpQfedLcYvPpCWYfIbecQgEZH6qKRcNCFxM vxj2TNLD0fWx0uT6bHgOwizPJGFUg4MfGvqmy7DY7inZBMWqVqjc32sR67r1QsBOa1wg EygW+LPWQe3w+AI+GImQ+nUA9AMaG0AIsWaLXBjUahijoGQrNBxqHe2ZjnPviCvI+5UG 6/r3d4rExOccLKj2TCccTS9zwkwJ150I1fHVL414Ml5TmmpugDdphW7yZJCydYu23fsu /bh1/OsX7C+BKpz+qbcpcHQ9f9nZh2NpIUj6XM/tBszF2BmIitglideCusJivijIWsE3 qfeg== X-Forwarded-Encrypted: i=1; AJvYcCX4LMemphNCaJgwnGYk05fOdWHbP3UiaUnZXMk73rwzxNkUBeIJ40/yfzVz1Lc7IMIOIBL2cDm8u5e+uiM=@vger.kernel.org X-Gm-Message-State: AOJu0YxZncEMmiRGxEYIUWvb2HMjoQSu3p+C4BJjoysqfgL26N04VerV u+TQgnBRfkoZ4DPCIMA0d/+snWLSKEZTdIM5ihnfU4RnTqfDnEGGrIKekTWWBFuLJThtux1MFxD SVQ== X-Google-Smtp-Source: AGHT+IFE06cZ1NoWP7OdXrOVjn1iSfUQVuTaoIxS0U6rhpG7UHzQY7xIVXmyFZZ8hLEzC/JwVgNzDqN73LU= X-Received: from pgbgb2.prod.google.com ([2002:a05:6a02:4b42:b0:86d:55d8:7944]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:8429:b0:1e1:e2d9:7f0a with SMTP id adf61e73a8af0-1eb2156f917mr659097637.34.1737067994607; Thu, 16 Jan 2025 14:53:14 -0800 (PST) Date: Thu, 16 Jan 2025 14:53:13 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240910200350.264245-1-mlevitsk@redhat.com> <20240910200350.264245-4-mlevitsk@redhat.com> <9ff2be87-117a-4f96-af3b-dacb55467449@redhat.com> <4c1c999c29809c683cc79bc8c77cbe5d7eca37b7.camel@redhat.com> Message-ID: Subject: Re: [PATCH v5 3/3] KVM: x86: add new nested vmexit tracepoints From: Sean Christopherson To: Paolo Bonzini Cc: Maxim Levitsky , kvm@vger.kernel.org, x86@kernel.org, Dave Hansen , Thomas Gleixner , Borislav Petkov , Ingo Molnar , "H. Peter Anvin" , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Thu, Dec 19, 2024, Paolo Bonzini wrote: > On 12/19/24 18:49, Maxim Levitsky wrote: > > > Here I probably would have preferred an unconditional tracepoint giving > > > RAX/RBX/RCX/RDX after a nested vmexit. This is not exactly what Sean > > > wanted but perhaps it strikes a middle ground? I know you wrote this > > > for a debugging tool, do you really need to have everything in a single > > > tracepoint, or can you correlate the existing exit tracepoint with this > > > hypothetical trace_kvm_nested_exit_regs, to pick RDMSR vs. WRMSR? > > > > Hi! > > > > If the new trace_kvm_nested_exit_regs tracepoint has a VM exit number > > argument, then I can enable this new tracepoint twice with a different > > filter (vm_exit_num number == msr and vm_exit_num == vmcall), and each > > instance will count the events that I need. > > > > So this can work. > Ok, thanks. On one hand it may make sense to have trace_kvm_exit_regs and > trace_kvm_nested_exit_regs (you can even extend the TRACE_EVENT_KVM_EXIT > macro to generate both the exit and the exit_regs tracepoint). On the other > hand it seems to me that this new tracepoint is kinda reinventing the wheel; > your patch adding nested equivalents of trace_kvm_hypercall and > trace_kvm_msr seems more obvious to me. > > I see Sean's point in not wanting one-off tracepoints, on the other hand > there is value in having similar tracepoints for the L1->L0 and L2->L0 > cases. I don't understand why we want two (or three, or five) tracepoints for the same thing. I want to go the opposite direction and (a) delete kvm_nested_vmexit and then (b) rename kvm_nested_vmexit_inject => kvm_nested_vmexit so that it pairs with kvm_nested_vmenter. Similary, having kvm_nested_intr_vmexit is asinine when kvm_nested_vmexit_inject captures *more* information about the IRQ itself. I don't see the point of trace_kvm_nested_exit_regs. Except for L1 vs. L2, it's redundant. kvm_nested_vmexit_inject and kvm_nested_vmenter are useful because they capture novel information. > I'll let him choose between the two possibilities (a new *_exit_regs > pair, or just apply this patch) but I think there should be one of these > two. Anything but a pair. Why can't we capture L1 vs. L2 in the tracepoints and call it a day?