From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1ED51CE7A88 for ; Fri, 22 Sep 2023 20:32:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229606AbjIVUc5 (ORCPT ); Fri, 22 Sep 2023 16:32:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229460AbjIVUcz (ORCPT ); Fri, 22 Sep 2023 16:32:55 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AAABCE for ; Fri, 22 Sep 2023 13:32:49 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id 41be03b00d2f7-5789f2f13fcso2384933a12.3 for ; Fri, 22 Sep 2023 13:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695414769; x=1696019569; 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=CSRAsOXqUG0ER0BOAKiobqvlHfjAj6fkRHJ850CANRE=; b=J/d+/vpX73JDiS99x6J8yXz7eWnsuKr3ZRSkH0+dqbPsGiMgSErvjDyDcSnOPlbMbX c92kmf7d3vLm0akowOAMssskLjzBOu6WHwoGv7i+IoY06CYHmPC7JDiPfqkHYxszWR+S 5ALElTT4Dv1JF8uPcP68fRvGglAwHATag0DQGrNRNPW4wSZrnKRnKpzrgqO0n1+1d1dY +X2wp9tSrebkCJ9H4JGlNWqL8B2+o37pasTalFdkwE6WnFCb9YFGn/Wax2+1025Cq9rt OQBZ8+S1T5Qw6kjzff8+UJwUqTg1JHPuKvgiWgHNXujhBHB1Wsbq+6htrBM4ToYywZWS /H5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695414769; x=1696019569; 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=CSRAsOXqUG0ER0BOAKiobqvlHfjAj6fkRHJ850CANRE=; b=I4xqCr66kgn8B5+a4jrRqm3OUPydsCYlVaH2v/CDO8+bZ01QgOe4tqsbya0c958Ybe 31yBmU5x6Ch6elEPmDdpv1qg24z0TLLgf2s/B6rbKsy3NuyjJPPQbzGpZdAUJwM78SJI XFWA4e9t7PU1MAw6SxtHyt+5PDEI9jqr399oxU39/c25nwzdAsAzAQdX1XG5nLyEi1hB 10ZhkY98WsKa8I2cBLYAIK6Lfjttpu8F5wXg9Yl+iQDGFAWFWgzEuIc3ydeey+fZ+bg5 fuP4m2cVYsJEImRIro2HB0crAtES2bLJm6gBRJjqVn2UHalI2D39OmzCcAnH9OTsqQVZ X8DA== X-Gm-Message-State: AOJu0Yw85S8AHG233H6nSVbXRtASCdn6mKF9Z1M0Tf3X+k8K7EXjWDiv WGZrrVoOJKtv+cbhYgqa8whsxqmRBCE= X-Google-Smtp-Source: AGHT+IEiBw59NffQePuDv4nERVBcRa7yli0EECdvxQRHySgvasoDIFxcuZKKvgHTJ5qWHHbpwqq2PFwVIKQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:fa8d:b0:1b9:df8f:888c with SMTP id lc13-20020a170902fa8d00b001b9df8f888cmr4603plb.8.1695414768675; Fri, 22 Sep 2023 13:32:48 -0700 (PDT) Date: Fri, 22 Sep 2023 13:32:47 -0700 In-Reply-To: <20230922194029.GA1206715@ls.amr.corp.intel.com> Mime-Version: 1.0 References: <20230922194029.GA1206715@ls.amr.corp.intel.com> Message-ID: Subject: Re: [RFC PATCH v2 0/6] KVM: gmem: Implement test cases for error_remove_page From: Sean Christopherson To: Isaku Yamahata Cc: isaku.yamahata@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, Michael Roth , Paolo Bonzini , erdemaktas@google.com, Sagi Shahar , David Matlack , Kai Huang , Zhi Wang , chen.bo@intel.com, linux-coco@lists.linux.dev, Chao Peng , Ackerley Tng , Vishal Annapurve , Yuan Yao , Jarkko Sakkinen , Xu Yilun , Quentin Perret , wei.w.wang@intel.com, Fuad Tabba Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 22, 2023, Isaku Yamahata wrote: > On Thu, Sep 21, 2023 at 01:29:59PM -0700, > Sean Christopherson wrote: > > > On Thu, Sep 21, 2023, isaku.yamahata@intel.com wrote: > > > From: Isaku Yamahata > > > > > > This patch series is to implement test cases for the KVM gmem error_remove_page > > > method. > > > - Update punch hole method to truncate pages > > > - Add a new ioctl KVM_GUEST_MEMORY_FAILURE to inject memory failure on > > > offset of gmem > > > > Doh. Please try to communicate what you're working on. I was just about to hit > > SEND on a series to fix the truncation bug, and to add a similar test. I would > > have happily punted that in your direction, but I had no idea that you were aware > > of the bug[*], let alone working on a fix. I could have explicitly stated that > > I was going to fix the bug, but I thought that it was implied that I needed to > > clean up my own mess. > > Oops sorry. Now I'm considering about machine check injection. > i.e. somehow trigger kvm_machine_check() and its own test cases. Unless we can't extend fadvise() for some reason, I think we should pursue FADV_HWPOISION. The enabling should be downright trivial, e.g. just implement file_operations.fadvise() for guest_memfd, have it handle FADV_HWPOISON, and pass everything else to generic_fadvise(). It'll basically be your ioctl() just without a dedicated ioctl(). At the very least, we should run the idea past the fs maintainers.