From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (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 D863F222575 for ; Thu, 19 Dec 2024 15:23:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734621840; cv=none; b=mnQsp9bkQ0T3O4PrlZ9kWJ/XAv0tq4Wytkn58WUWYbbYPzUQdG43/jj58As11zD/lh8/Zke/bfBn8i60T/4j9LaH8cNdP+CvR13YTNmVM5M2X6ngvkdQUYNsWrUfSts+hGm4ZiAnoL6bOqDsS/4X74NaU+CZ7S7W3mb3uYIKR+8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734621840; c=relaxed/simple; bh=vQ52mRiElqCZNzqac3CSN8kfDYDhKf+LTt9VTB9knUM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=SfledfWJEeIbtsUUCMN1tr9ds8KHzL7kD1PnpfKi9FvRfnrvLTxBbbQm8RV6HK9XUMF/mfFPeG19xZ6sdx1DCrtu6EFm03Hs7JxCR7QWsghQsnKnmKXyCRK6Pn3/s7XvaD6m2rTWaFVaHjG+IVNpRzx9Itjjmwjhsp0ygiBh238= 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=AKXo0KBP; arc=none smtp.client-ip=209.85.210.201 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="AKXo0KBP" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-728f1c4b95aso961703b3a.0 for ; Thu, 19 Dec 2024 07:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1734621838; x=1735226638; 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=tWsNmzzST8lcMxSYcBiJLWeTL6YuFmSorOwIwOomjFE=; b=AKXo0KBPpF20Nk7y2gEsktTi7MxfhjFPHIUscAF5WukhU05OMGF5EHIGf5kblKmHKO Xk2oq+GUOUnuKXeGMT5A3kMJSR4Hnff4ud/lDrJ3zHQTjs/n3yfs2Gc6AxQE/kSgPenN EZ4jOD58Jl9CoXB8YH45Hy9xCkMyALZ39vpim6Ow8Pa7CQUwXwGjSviPRIbYQDVmHbFn Rh0GBj4quGN1qw6B92FwGWBP8FLEewMbowijB9vBxpO4GP1ZK2WxBxM4uVTgIZVBPfSv F7oruY/hv57IXicNvoMoxWYlmNsaWww5mjh5RTmkYSLpRsgV+w/7fz26kUNums5M+jCX mxmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734621838; x=1735226638; 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=tWsNmzzST8lcMxSYcBiJLWeTL6YuFmSorOwIwOomjFE=; b=qYHWgzJIwnasCsXIniQ6Zg33D6DLUXKT+R6hXfgxwfS98oRXvpya55r4GjiVoc4ZgT T6JKRneW+ub3ToWnq7QmiL9VMeZYf8l98GZFgqe3aarASPG0gBddG7D0p82AlKbo1nqL SusqVcztPHlHvibp6NPcO56dqODgdAeu3UmMVkMlnzvxsLPXV4JsNssqd6ROUwtiMAQC ob62Nti7A9PWZSlbNWYdCa3JGix25M3+OthkFa5HpRZMAMNLzj6+/KsYqGhJsuBF2c/v zkxihEATG5iD0fy1scmfSmecofnBG1h0qgV40OdPnzK5jsEtazZ5CjYbYFr5fuHPMwMg RHuw== X-Forwarded-Encrypted: i=1; AJvYcCUpbkr9RW3oyGbm2U3GIxLsDPY9Xz2kmBU0UWZT2BWapElIiNsz7oxfFnUjdrLqCOb6Xw4p3xhxbqxb5QE=@vger.kernel.org X-Gm-Message-State: AOJu0Yzvt45pA8nrxlMER+PpATYQuV9lwAg+JC6FU+mSB4xzCg8hSfET k7d2yR6dFEpDfkz2D9d88fIJPG8EraEBZVcHOaci3Dc76wpcxzYXk+YtawTLUnEWelTGB9kIaQF ALw== X-Google-Smtp-Source: AGHT+IGmUvtSYpU2PNr3cYRU0AgkhwMuw643VsMeCpo/v6gnGPtYySVv5u88L3bISsqAABXTw/MmgDxPDcE= X-Received: from pfbeh4.prod.google.com ([2002:a05:6a00:8084:b0:728:958a:e45c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1311:b0:72a:8b90:92e9 with SMTP id d2e1a72fcca58-72a8d0310c1mr12598351b3a.5.1734621838249; Thu, 19 Dec 2024 07:23:58 -0800 (PST) Date: Thu, 19 Dec 2024 07:23:56 -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: <20241214010721.2356923-1-seanjc@google.com> <20241214010721.2356923-10-seanjc@google.com> <39f309e4a15ee7901f023e04162d6072b53c07d8.camel@redhat.com> Message-ID: Subject: Re: [PATCH 09/20] KVM: selftests: Honor "stop" request in dirty ring test From: Sean Christopherson To: Maxim Levitsky Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Xu Content-Type: text/plain; charset="us-ascii" On Thu, Dec 19, 2024, Maxim Levitsky wrote: > On Wed, 2024-12-18 at 18:00 -0800, Sean Christopherson wrote: > > On Tue, Dec 17, 2024, Maxim Levitsky wrote: > > > On Fri, 2024-12-13 at 17:07 -0800, Sean Christopherson wrote: > > > > Now that the vCPU doesn't dirty every page on the first iteration for > > > > architectures that support the dirty ring, honor vcpu_stop in the dirty > > > > ring's vCPU worker, i.e. stop when the main thread says "stop". This will > > > > allow plumbing vcpu_stop into the guest so that the vCPU doesn't need to > > > > periodically exit to userspace just to see if it should stop. > > > > > > This is very misleading - by the very nature of this test it all runs in > > > userspace, so every time KVM_RUN ioctl exits, it is by definition an > > > userspace VM exit. > > > > I honestly don't see how being more precise is misleading. > > "Exit to userspace" is misleading - the *whole test* is userspace. No, the test has a guest component. Just because the host portion of the test only runs in userspace doesn't make KVM go away. If this were pure emulation, then I would completely agree, but there multiple distinct components here, one of which is host userspace. > You treat vCPU worker thread as if it not userspace, but it is *userspace* by > the definition of how KVM works. By simply "vCPU" I am strictly referring to the guest entity. I refered to the host side worker as "vCPU woker" to try to distinguish between the two. > Right way to say it is something like 'don't pause the vCPU worker thread > when its not needed' or something like that. That's inaccurate though. GUEST_SYNC() doesn't pause the vCPU, it forces it to exit to userspace. The test forces the vCPU to exit to check to see if it needs to pause/stop, which I'm contending is wasteful and unnecessarily complex. The vCPU can instead check to see if it needs to stop simply by reading the global variable. If vcpu_sync_stop_requested is false, the worker thread immediated resumes the vCPU. /* Should only be called after a GUEST_SYNC */ static void vcpu_handle_sync_stop(void) { if (atomic_read(&vcpu_sync_stop_requested)) { /* It means main thread is sleeping waiting */ atomic_set(&vcpu_sync_stop_requested, false); sem_post(&sem_vcpu_stop); sem_wait_until(&sem_vcpu_cont); } } The future cleanup is to change the guest loop to keep running _in the guest_ until a stop is requested. Whereas the current code exits to userspace every 4096 writes to see if it should stop. But as above, the vCPU doesn't actually stop on each exit. @@ -112,7 +111,7 @@ static void guest_code(void) #endif while (true) { - for (i = 0; i < TEST_PAGES_PER_LOOP; i++) { + while (!READ_ONCE(vcpu_stop)) { addr = guest_test_virt_mem; addr += (guest_random_u64(&guest_rng) % guest_num_pages) * guest_page_size;