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 3F971EB64D9 for ; Wed, 12 Jul 2023 09:45:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232892AbjGLJpa (ORCPT ); Wed, 12 Jul 2023 05:45:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232777AbjGLJp3 (ORCPT ); Wed, 12 Jul 2023 05:45:29 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CB691739 for ; Wed, 12 Jul 2023 02:45:24 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3144098df56so7584562f8f.2 for ; Wed, 12 Jul 2023 02:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689155123; x=1691747123; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=BeHjmBMqae1zfZ9d1o7CDW2GBVL1eDyXHOBTuOaNFYg=; b=AH7cKSqAEvP2fqllKNUyTI6gGKtCoyOQcYze+d458Wne9rqOzCSA2nbNX0VOORk2ey jm7uZ2EG4i5+/RqwbtiPmiCHkqW7dNCfzEO2d0C6p++7CSaBagms4S+DBb0SWWvWfR52 1fJNHgSiLTnlE+FwxtySO/TCT3WcfE1ztbhyFusZQiljr8ILDyysnD94riJoZrQv7RUw WoVPS4vXtlpt8mLHgAaDbGh21i1VHozDdmS3E9wTRYRM3Z2s5mjMequ4pgQV272XdcYj WYtXphFKBsU+NLbyj8H5Dysp2/YaIY/8mteiWJN7toASik1RaH7KY1LdrxZTXkZWKg29 wXrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689155123; x=1691747123; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BeHjmBMqae1zfZ9d1o7CDW2GBVL1eDyXHOBTuOaNFYg=; b=AkwfMWkmorEgKIl+clsoMILeLnk/CPQYd3YUEdbH+DQBpTQsSIDVN/v9fYIK/S/uV6 /mdyGbw0k+k28Kc/z6Zk5+OyrBlY147s/Mv3pluvIvpV60hZdIrtD8ID67NrtyIqiTiX KtlPZMereneHhsW+aRscTq/+XyIkuQHJE0eICWCUG5QzkwC86JZExfwYZFcbLE76658w YkYkaZtARFmYPW7YOifkH3lH7Dk567x3+dNB6copb4B4aW7GK2XXZZympBVdK90BayQC eb0eunyfBRqan7+337mOJq54KcHvtMCEPE12tUZELvyDx9J9TJekSsJM9wMwq6tTQHg6 9ssQ== X-Gm-Message-State: ABy/qLZWzVGeMrghwO15OxNuX53qafjmHryLkduwSa28hTUurZUw8GfO dtaWJZ9FEFVTCRfANasJzGGHCg== X-Google-Smtp-Source: APBJJlHrEeMT+kJGs1oHD4HOzLI6iswJjrdlJA8OCycHTa0XqhhKKvXc0gGBPcdwUB5hP77AXSiBZQ== X-Received: by 2002:a5d:56cd:0:b0:314:3983:1465 with SMTP id m13-20020a5d56cd000000b0031439831465mr18892557wrw.31.1689155123166; Wed, 12 Jul 2023 02:45:23 -0700 (PDT) Received: from myrica ([2.219.138.198]) by smtp.gmail.com with ESMTPSA id t12-20020a5d6a4c000000b00314329f7d8asm4577438wrw.29.2023.07.12.02.45.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jul 2023 02:45:22 -0700 (PDT) Date: Wed, 12 Jul 2023 10:45:22 +0100 From: Jean-Philippe Brucker To: Baolu Lu Cc: "Tian, Kevin" , Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Nicolin Chen , "Liu, Yi L" , Jacob Pan , "iommu@lists.linux.dev" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 3/9] iommu: Add common code to handle IO page faults Message-ID: <20230712094522.GB507884@myrica> References: <20230711010642.19707-1-baolu.lu@linux.intel.com> <20230711010642.19707-4-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, Jul 12, 2023 at 10:32:13AM +0800, Baolu Lu wrote: > > btw is there value of moving the group handling logic from > > iommu_queue_iopf() to this common function? > > > > I wonder whether there is any correctness issue if not forwarding > > partial request to iommufd. If not this can also help reduce > > notifications to the user until the group is ready. > > I don't think there's any correctness issue. But it should be better if > we can inject the page faults to vm guests as soon as possible. There's > no requirement to put page requests to vIOMMU's hardware page request > queue at the granularity of a fault group. Thoughts? Not sure I understand you correctly, but we can't inject partial fault groups: if the HW PRI queue overflows, the last fault in a group may be lost, so the non-last faults in that group already injected won't be completed (until PRGI reuse), leaking PRI request credits and guest resources. Thanks, Jean