From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30ECA22756A for ; Thu, 19 Dec 2024 15:57:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734623828; cv=none; b=mRZWqM6iVWr6LMecf590SqiOrgqZOpHMHtg8w6CRughgJpwg0uQJRDfEdr/Urjpp3jDVShPa9a22ZVelhInxat4rzvMZ+3FglZ4/SvarYeT2AXuwxxtgW7nksFAtQxaxXM7QywTfBZlYBNqMAOPc2kAYbnJnU5/J+hl3xKfzrU4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734623828; c=relaxed/simple; bh=NZXbDOnsbueY/bTYnolr7LLXf3fkhWEB1EVBmrjmw3s=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=aX7hlITITFdPi5h53gQAX1q7cc4Lzs/BUu45NN0TPLjQ9mT/C9UED1nH4xd9HPOKIsiyBmfeqqaFv/uvC9cMh5FjXK+35/q3o0BBdKWQKyoMtJyc1HVKBCZcCbyiqf40uppCPQXGtMVZl9Pan/PGq/oJaWCB77nYh28XunbDr4k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HGjeLgGe; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HGjeLgGe" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734623824; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BSRf2lahUcjGUrwQe+FmSLq/2A9QSO0QlymJM9SaP8g=; b=HGjeLgGesdKTcvw6l0FXS7haCsvieYDsACCnvVSkL7914CoCfLM8EBJPIZeEsG5/+PL22q 33Xxk2rqvzY2poYC4TAb8QKEvHTec9Ty7rxjo5/T50f4DHvL0RccrgQB48OVOrEPCPPdr9 7Kkr9ynsVEo5wORQiXsv1jEUSW8WDSk= Received: from mail-il1-f199.google.com (mail-il1-f199.google.com [209.85.166.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-468-hWmIR4D9P9yE4op47MUe2w-1; Thu, 19 Dec 2024 10:57:02 -0500 X-MC-Unique: hWmIR4D9P9yE4op47MUe2w-1 X-Mimecast-MFC-AGG-ID: hWmIR4D9P9yE4op47MUe2w Received: by mail-il1-f199.google.com with SMTP id e9e14a558f8ab-3a817be161bso8659595ab.1 for ; Thu, 19 Dec 2024 07:57:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734623822; x=1735228622; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=BSRf2lahUcjGUrwQe+FmSLq/2A9QSO0QlymJM9SaP8g=; b=RZd1aq63YLKdimz2uJqJGszI/kjCacX6bgyIbS/vmWq813QC/0RTszwCLpd6kuw+g0 Zs2i7jihAJLuyeSesEvO6+OsbV2ltr88MNpCtcFMAv0nru6OBkGUGco3aDgCS7Ncd9ah TxAeJqeKyO4ep3Imd2Ze3gFTdXycjrJuqtkolp3Rw7S6ihecuIZlPHt3DAQExCe+76Nb 59a/2ZdUp9aFiB3EThj166L5vasTEh80l9rmVgMKqR9HHB8tCZ9cEG5685V0oX58BIp8 R+27d2a8yrvOR+vzkydWIVXHD5pe5TYUzonVljj8CiNqvFzB555vriMqOg6KulzdktO/ YQOw== X-Forwarded-Encrypted: i=1; AJvYcCXQnOGq97sVsIVjlQFuhrKsq+6t4SFNPcIKSk+CQ9IoETBiSh8NViQhpJI3FL7je7EHZWDAiC7ZpcXnLcQ=@vger.kernel.org X-Gm-Message-State: AOJu0Ywud7CTrt5wqNwWAx5Lw2C/3cy1fEOBbJNWVyM+aOdiOR+rPP+K 73KQ4n+6MilKse8uKlQbnIKRFl3zVpIX+4ZA0f/unK0PVGJYUINeCtNDthNQToGwAuLQsEXZrZM Fz9FY4U5zgZQrUBr/3DBmH7I416N1u+K/RCzV8ThwjwqJhO+HSvrVnBGSE85/gGrOS6V78Q== X-Gm-Gg: ASbGncvCrbJilcfIwszM4ovYwuR8v3lAzE7MvaRg2yyDHyxPgwCHk2lry6GHzcsh5pG XSvb7DzwUSMBw6rrVZwi1J0IpEYDCP0eCbqNCGsjbhICAs5qRcGpgTvKraTBchNuk2spX+kdPyZ rZSOL7jI5kBeLqmNELnHtUZUGOfToUgeTSCctEKS0WNk6Rw+uWLeHjrBy8Xhh8fR4uoZ+RD2OIB qath2tpR5XmG1uYjrBm/U1q6Y3mtp54mk+X6JuV9d+3XaBr2plhxwIv X-Received: by 2002:a05:6e02:3b03:b0:3a7:d02b:f653 with SMTP id e9e14a558f8ab-3c02773b83emr24377805ab.0.1734623822066; Thu, 19 Dec 2024 07:57:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IFTroMO2mMF9jsTs4bhAlwpMmc55xNPTwCrKo0X1dMF4R3mM/rFQFiTHfNe78bttZIpNUF0Aw== X-Received: by 2002:a05:6e02:3b03:b0:3a7:d02b:f653 with SMTP id e9e14a558f8ab-3c02773b83emr24377655ab.0.1734623821762; Thu, 19 Dec 2024 07:57:01 -0800 (PST) Received: from starship ([2607:fea8:fc01:8d8d:6adb:55ff:feaa:b156]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3c0de052f2dsm3679865ab.9.2024.12.19.07.57.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Dec 2024 07:57:01 -0800 (PST) Message-ID: Subject: Re: [PATCH 09/20] KVM: selftests: Honor "stop" request in dirty ring test From: Maxim Levitsky To: Sean Christopherson Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Xu Date: Thu, 19 Dec 2024 10:57:00 -0500 In-Reply-To: References: <20241214010721.2356923-1-seanjc@google.com> <20241214010721.2356923-10-seanjc@google.com> <39f309e4a15ee7901f023e04162d6072b53c07d8.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit On Thu, 2024-12-19 at 07:23 -0800, Sean Christopherson wrote: > 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; > Ah OK, I missed the "This *will* allow plumbing", that is the fact this this patch is only a preparation for this. Best regards, Maxim levitsky