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 D0B051C28E for ; Wed, 18 Dec 2024 00:00:43 +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=1734480045; cv=none; b=c+ndV++vRsVtRkAWEKiRlme/IUGrkcZ0Twh9H2ClQC/CpLZN9Y9A7DpPFMi5GKKwv/GB/DpZuCSsuP1ThqP+2mZkRovg09/ymA3PMupPIgpmd+AxSu4o+gyV2rnQrniaDkl/cl3UmrFcOzqhfBE9RDeqDhIcnqbDb2KZHrds6PU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734480045; c=relaxed/simple; bh=IEclRw50IlWafe/HOJ55QWSCxVIkHZZ0nGPNVoJiLWw=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=GTth2qMtRnRna729NPPYjk0PBsrJKw4QJIW+c7bW23UsFCKVMySOcuv/omef4GqEK7Rst+95tVnqqxYR2h0FwxQUYi/Lx2dWr+1Lw4eYSMlajmdIBcYZ9eX8w6g54aPWlpFYEWbVeQBysAT5kbpEMd8UFCC46oN50I7g3dDE5O0= 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=P42JQ0QB; 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="P42JQ0QB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734480043; 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=GAB7b7lxkUE0WLtI3lfSURqgKFaDexqrbJ32hTQPVN4=; b=P42JQ0QBE96b5iZaiI/2HP0/OwXyjab4VoxCdpkEm7bZxGjC8ad3OvqNwWdgOqWhFsy6sJ T3F+JNWfvFyv9LnzSeSBIRpRe+mApx1ChTpRgANKN27Bkyw5c/TK4kQKQq/Ix1s75K1hZu fMwVL0OdhUTBuKtDSi40GPTrbQ0/IBk= Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-688-IMNl2CWgMRqFZq8h1NSTSg-1; Tue, 17 Dec 2024 19:00:41 -0500 X-MC-Unique: IMNl2CWgMRqFZq8h1NSTSg-1 X-Mimecast-MFC-AGG-ID: IMNl2CWgMRqFZq8h1NSTSg Received: by mail-io1-f70.google.com with SMTP id ca18e2360f4ac-844e344b0b5so493939339f.0 for ; Tue, 17 Dec 2024 16:00:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734480041; x=1735084841; 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=GAB7b7lxkUE0WLtI3lfSURqgKFaDexqrbJ32hTQPVN4=; b=Qhmtl5f7mRM2dRg7B1IhfdMs02Ow/X/mZP3EQp7XANN+3NQoZvpdx6J6d7RVnKPMxt BeOFQCtDqonGq6q57PvsznE2NjPNslAcLaxGB+9sVXITS0AM+MD/3prd+mWmp/SjMqK4 9yfEQseZS3Ffou8xwa6u+gtvxVQbbcOCbrp5e6LBYeTxdPKtVq1gfJs5N9cEiXBTSXYb Al1ee/bAiSJs7fAZJyRDvCdGa2LSqSJy0kvum/Wvg6y6pu/OjwWsP1m3AXM7L6CkwxV5 3Ti8hAt95vACnIIVApgcFlHowy1669kMqoent8/4gtB1eSa+YjIJsGrnResib1OgOHqp ph+w== X-Forwarded-Encrypted: i=1; AJvYcCVi+M6YdLv3f9U1f7SC8Q/OOghOFlLtt7PKjjxwRJ0s+2jm/8uPl6doPKLrVV+UhFfdQyMYED2FreZvgRw=@vger.kernel.org X-Gm-Message-State: AOJu0YwQfmFO5mbmHqk5d21rQormFYlkOaiwF7deyJ3tjfyQM/OwhcJo UuJcjrmC7Ztb0PVzi1c40L1sMHwGklXM5UIFBY1he/4wQerDathfuhZWZaXc1+7GFC65dau8Fp/ gtrTRl3iJA1UKkQ6u/Wep/Xt1pJ1ObhP9mox+HuFaEzqIQUFCIfv98k4iMdd4iw== X-Gm-Gg: ASbGnctmQBC1d+9sLpYqw33S8hK80AFp+wvVMRsRYcdsLIlCmFnwMh07M8YYwzP5KF4 /pvfg7tAC6TdiLdsFtyPbZ3fPhMuQ/Zkqo35vbBdkJp3cCVFdFDNfryHToWfeAkrQDC4k+NRPYn QNuql3+SRkje6YTdwDrZCu/7h7ZdeakBG4xy8RHb78Et9s7C3nqKeUHWQvBLEfkh+oRUJlJGiXc 2wJdQ8lFQLU3htGWWSz1foOYSCNn0aZiG2xWOIsY5QOI3SyVcME+9aR X-Received: by 2002:a05:6602:1585:b0:844:c750:3d9d with SMTP id ca18e2360f4ac-8475854466bmr90732039f.4.1734480040661; Tue, 17 Dec 2024 16:00:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IGth+e7OyhRPQ8Kdsm84tbHhPWSeCUqVX6p60mHRdsiga7HMV4fbdzjLhEtmh+qbu+WQcFpMA== X-Received: by 2002:a05:6602:1585:b0:844:c750:3d9d with SMTP id ca18e2360f4ac-8475854466bmr90728839f.4.1734480040341; Tue, 17 Dec 2024 16:00:40 -0800 (PST) Received: from starship ([2607:fea8:fc01:8d8d:6adb:55ff:feaa:b156]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4e5e32a33e3sm1927436173.85.2024.12.17.16.00.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Dec 2024 16:00:40 -0800 (PST) Message-ID: <39f309e4a15ee7901f023e04162d6072b53c07d8.camel@redhat.com> Subject: Re: [PATCH 09/20] KVM: selftests: Honor "stop" request in dirty ring test From: Maxim Levitsky To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Xu Date: Tue, 17 Dec 2024 19:00:39 -0500 In-Reply-To: <20241214010721.2356923-10-seanjc@google.com> References: <20241214010721.2356923-1-seanjc@google.com> <20241214010721.2356923-10-seanjc@google.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 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. > > Add a comment explaining that marking all pages as dirty is problematic > for the dirty ring, as it results in the guest getting stuck on "ring > full". This could be addressed by adding a GUEST_SYNC() in that initial > loop, but it's not clear how that would interact with s390's behavior. I think that this commit description should be reworked to state that s390 doesn't support dirty ring currently so the test doesn't introduce a regression. > > Signed-off-by: Sean Christopherson > --- > tools/testing/selftests/kvm/dirty_log_test.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/tools/testing/selftests/kvm/dirty_log_test.c b/tools/testing/selftests/kvm/dirty_log_test.c > index 55a385499434..8d31e275a23d 100644 > --- a/tools/testing/selftests/kvm/dirty_log_test.c > +++ b/tools/testing/selftests/kvm/dirty_log_test.c > @@ -387,8 +387,7 @@ static void dirty_ring_after_vcpu_run(struct kvm_vcpu *vcpu) > > /* A ucall-sync or ring-full event is allowed */ > if (get_ucall(vcpu, NULL) == UCALL_SYNC) { > - /* We should allow this to continue */ > - ; > + vcpu_handle_sync_stop(); > } else if (run->exit_reason == KVM_EXIT_DIRTY_RING_FULL) { > /* Update the flag first before pause */ > WRITE_ONCE(dirty_ring_vcpu_ring_full, true); > @@ -697,6 +696,15 @@ static void run_test(enum vm_guest_mode mode, void *arg) > #ifdef __s390x__ > /* Align to 1M (segment size) */ > guest_test_phys_mem = align_down(guest_test_phys_mem, 1 << 20); > + > + /* > + * The workaround in guest_code() to write all pages prior to the first > + * iteration isn't compatible with the dirty ring, as the dirty ring > + * support relies on the vCPU to actually stop when vcpu_stop is set so > + * that the vCPU doesn't hang waiting for the dirty ring to be emptied. > + */ > + TEST_ASSERT(host_log_mode != LOG_MODE_DIRTY_RING, > + "Test needs to be updated to support s390 dirty ring"); This not clear either, the message makes me think that s390 does support dirty ring. The comment above should state stat since s390 doesn't support dirty ring, this is fine, and when/if the support is added,then the test will need to be updated. > #endif > > pr_info("guest physical test memory offset: 0x%lx\n", guest_test_phys_mem); Best regards, Maxim Levitsky