From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 0F6821FBEB6 for ; Wed, 18 Dec 2024 21:36:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734557819; cv=none; b=fNMm3NA2C9Yj4ppaXWTznZZxt0lxyejU6uJWvC8WWitCWjzcW3roMY4NUJVFnY3jCvaAlaxoHboKXeAgOyZJmaQFBkNReAFDwUfAWhay7fxipdkJA+HcR34ACv1ShftXmuVjVbhEZfsv67A/yQs2gnSjx/lcCvvE0Vkok9Mhz7Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734557819; c=relaxed/simple; bh=XPuo/CZn2Usv+9YMqDzuAf+BZP+rPD7a5SSHClAT9sI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=HyDB+TNo3TwEfM8VuK6VuGHs/SCGzLCCJqYvOf6mEacZFEBb5wJaB/lIGncV5c7SK0bkU71lfZz4qDJccta+heRS5eF/J7o3jfk9oBCMHYUvHqQ9dRIDtqMTwVKIHFUjLESfmhBCdMe/KvOqEWq7yBNMTxT9cnaxqBO+8b2/d5c= 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=PNYL+0JO; arc=none smtp.client-ip=209.85.216.74 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="PNYL+0JO" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2ef909597d9so137648a91.3 for ; Wed, 18 Dec 2024 13:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1734557817; x=1735162617; 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=EyaJhiMjuIL9HY6dyZK3annl/R0dDwtO/JJB1kPLtXM=; b=PNYL+0JORonSRK25prudWpEFm9Qe7/mSCT8qqlw5G+jvSPOhCiLPLzwFovPjVlmfQ2 2PIH9IVlInKYZoiYwa6drNRJmXlm5U18CXt+jy67NE5KwHhYD+Wt+nY3w6tAVEa17V1F jdBP3MYKWYChbx9b5Mi/reZ1uKyTP6aztG+9+aR9vZ6n6hm4pHkQH8ZaRWNe/lTDpC85 UKN3KTDtpQkbuUyXNqunEuuNdqF2G2WfnggZopEFpxD9pYLNpO56PfR8OH/NkQlHawFu WxRAEa/qTTCYeVKCgWujEYztOjQ6hvrdfV2t3WjQMhBmlOskIi96OfdW/1qrcmv+nGOi W+VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734557817; x=1735162617; 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=EyaJhiMjuIL9HY6dyZK3annl/R0dDwtO/JJB1kPLtXM=; b=i3v2qFe/cDZDI2omVfUmmlD1hYpw/VW2MQqjvIC+U0KNlVrWOsHJojkpN984o9fKgc Sos5eFztQgITpAJNG5E53lUOAWb1nyjFWEZrPoXlRapDdG3Twg8C25fQYcFf/9jfhcId 0dXX+0J/YwoLBWxPoedJM0oRHOvOeg9AdgO3lUoDTxlGi9xAKLTRJjZ6VNVy6AmbiCY4 Ic0IslBaZ9Bwb72EyN0ZJz3oKnC/UNpySaex3Mws92D5GfMFdQGbufn/MkVBz6RHa0kY JMKGm31p7sCogMEdoZo5ZTxfSJjS8jzBtUxzYVFlO/hVMht1IZxCKDhzNrBcWpN9ycyq BdBQ== X-Forwarded-Encrypted: i=1; AJvYcCVxmSTgJvIQMMfDSowZseK5D/YhQkYIFe4Xu/JeyC60OiHBPUgmgCQCRz6V4wNpZV1O48YLU2uH9aZUhZs=@vger.kernel.org X-Gm-Message-State: AOJu0Yxkvk9FSUus1wNVQxgvSSMgh7bapVVAdFV9lW3yjy2tJV4394Jf HczL8RPChsQbZZJpZjhjb1VKWDT+FY/hWIybERpBbur3OkqyUvkDqfBODHjwr31MQeDX4RihllC HRw== X-Google-Smtp-Source: AGHT+IHMB5G/YaAxG4Rmui13Dlu0Ftb95T2/skLpSUbdJAmz3y6tgGwkpKUDfoCoCCHcVKSk8CO9mYVVar0= X-Received: from pja15.prod.google.com ([2002:a17:90b:548f:b0:2ef:9ef2:8790]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2ed0:b0:2ee:c4f2:a76d with SMTP id 98e67ed59e1d1-2f2e91f9f3cmr5450681a91.21.1734557817474; Wed, 18 Dec 2024 13:36:57 -0800 (PST) Date: Wed, 18 Dec 2024 13:36: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-3-seanjc@google.com> Message-ID: Subject: Re: [PATCH 02/20] KVM: selftests: Sync dirty_log_test iteration to guest *before* resuming 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 Tue, Dec 17, 2024, Maxim Levitsky wrote: > On Fri, 2024-12-13 at 17:07 -0800, Sean Christopherson wrote: > > Sync the new iteration to the guest prior to restarting the vCPU, otherwise > > it's possible for the vCPU to dirty memory for the next iteration using the > > current iteration's value. > > > > Signed-off-by: Sean Christopherson > > --- > > tools/testing/selftests/kvm/dirty_log_test.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/tools/testing/selftests/kvm/dirty_log_test.c b/tools/testing/selftests/kvm/dirty_log_test.c > > index cdae103314fc..41c158cf5444 100644 > > --- a/tools/testing/selftests/kvm/dirty_log_test.c > > +++ b/tools/testing/selftests/kvm/dirty_log_test.c > > @@ -859,9 +859,9 @@ static void run_test(enum vm_guest_mode mode, void *arg) > > */ > > if (++iteration == p->iterations) > > WRITE_ONCE(host_quit, true); > > - > > - sem_post(&sem_vcpu_cont); > > sync_global_to_guest(vm, iteration); > > + > > + sem_post(&sem_vcpu_cont); > > } > > > > pthread_join(vcpu_thread, NULL); > > > AFAIK, this patch doesn't 100% gurantee that this won't happen: > > The READ_ONCE that guest uses only guarntees no wierd compiler optimizations > are used. The guest can still read the iteration value to a register, get > #vmexit, after which the iteration will be increased and then write the old > value. Hmm, right, it's not 100% guaranteed because of the register caching angle. But it does guarantee that at most only write can retire with the previous iteration, and patch 1 from you addresses that issue, so I think this is solid? Assuming we end up going with the "collect everything for the current iteration", I'll expand the changelog to call out the dependency along with exactly what protection this does and does not provide > Is this worth to reorder this to decrease the chances of this happening? I am > not sure, as this will just make this problem rarer and thus harder to debug. > Currently the test just assumes that this can happen and deals with this. The test deals with it by effectively disabling verification. IMO, that's just hacking around a bug.