From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 5E56E178883 for ; Mon, 25 Mar 2024 04:03:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711339423; cv=none; b=gTzDvzPcM9cdVI+GFVN/tnZ0LhKOhd/tuGXYmv/LriSO6xy8nf1d+UpxJqSjZL1k8ISdg12w6WXi9qiATXS41vSpqACE0S10U/W5GVVIEkeu71WAYL+CHrNVTy4ldGzTOyMhm8SnGz+9bzvan3Br2ejYYP66ZEVteTTY83Ya7uI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711339423; c=relaxed/simple; bh=alvrRycuvN6pDESIAsTl9Hn3uiuLSuA+BX27ZLzTuY0=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=iKRDORc75IluM/LzxCraevJbm1hl6oVuWRPwzGwyEKvbiPII/zcjfF4EnE9s0cJknQbLtqdrkKMSrjw2luOtcUhb+Rn7kC9PvggGHrJM0HN/hLIhMJxZN0cr2uVn+EqjGrp44r9qxo26WzrU5aPiECmEs3eXHM1OBEEHeZXgo/Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=jeNxEWIy; arc=none smtp.client-ip=192.198.163.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="jeNxEWIy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711339423; x=1742875423; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=alvrRycuvN6pDESIAsTl9Hn3uiuLSuA+BX27ZLzTuY0=; b=jeNxEWIyYtscQIyDMPLswSlx3doZTocVRmz5xOP1WUqPNXWCcWCIaYCt faU8JcnTkU+Ez8SFTzWJNdJg4U67FEFDPlrpPh0lbuBJv+nBrJ7g5fMRG YS4CdneICKD0n/000DYHg/1HGwObSXJPhnChuhyF9OiOqUmEnrzCMhgLF +esugn42blR7ZlHHyPYy+hcGGUSk3Pl7RLRQk54noVMn/8qo1PF42I/JF hk7jBhCiz2ZBO7zymQgPN1y43K7qOhE+nxyk1KbFbbDC//q5Mab8hoX6F BRNgI/ifstWtuVkRnUjqMvefcS+I/U7vBowKVnUEr+QN5m6ZOcqWczOy0 g==; X-IronPort-AV: E=McAfee;i="6600,9927,11023"; a="17717928" X-IronPort-AV: E=Sophos;i="6.07,152,1708416000"; d="scan'208";a="17717928" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2024 21:03:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,152,1708416000"; d="scan'208";a="38594548" Received: from allen-box.sh.intel.com (HELO [10.239.159.127]) ([10.239.159.127]) by fmviesa002.fm.intel.com with ESMTP; 24 Mar 2024 21:03:38 -0700 Message-ID: <4c226b87-3716-4987-b6ef-1693733614bd@linux.intel.com> Date: Mon, 25 Mar 2024 12:02:47 +0800 Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: baolu.lu@linux.intel.com, Kevin Tian , Joerg Roedel , Will Deacon , Robin Murphy , Jean-Philippe Brucker , Nicolin Chen , Yi Liu , Jacob Pan , Joel Granados , "iommu@lists.linux.dev" , "virtualization@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 4/8] iommufd: Add iommufd fault object Content-Language: en-US To: Jason Gunthorpe , Shameerali Kolothum Thodi References: <20240122073903.24406-1-baolu.lu@linux.intel.com> <20240122073903.24406-5-baolu.lu@linux.intel.com> <20240322172232.GK66976@ziepe.ca> <45fc6507-f077-4626-98cb-96cda1585718@linux.intel.com> From: Baolu Lu In-Reply-To: <45fc6507-f077-4626-98cb-96cda1585718@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/25/24 11:26 AM, Baolu Lu wrote: > On 3/23/24 1:22 AM, Jason Gunthorpe wrote: >> On Wed, Mar 20, 2024 at 04:18:05PM +0000, Shameerali Kolothum Thodi >> wrote: >>> What I have noticed is that, >>> -read interface works fine and I can receive struct >>> tiommu_hwpt_pgfault data. >>> -But once Guest handles the page faults and returns the page response, >>>   the write to fault fd never reaches the kernel. The sequence is >>> like below, >>>    sqe = io_uring_get_sqe(ring); >>>    io_uring_prep_write(sqe, hwpt->fault_fd, resp, sizeof(*resp), 0); >>>    io_uring_sqe_set_data(sqe, resp); >>>    io_uring_submit(ring); >>>    ret = io_uring_wait_cqe(ring, &cqe); >>>    .... >>> Please find the function here[2] >>> >>> The above cqe wait never returns and hardware times out without >>> receiving >>> page response. My understanding of io_uring default op is that it >>> tries to >>> issue an sqe as non-blocking first. But it looks like the above write >>> sequence >>> ends up in kernel poll_wait() as well.Not sure how we can avoid that for >>> write. >> Ah, right, it is because poll can't be choosy about read/write, it has >> to work equally for both directions. iommufd_fault_fops_poll() never >> returns EPOLLOUT >> >> It should just always return EPOLLOUT because we don't have any queue >> to manage. > > Are you suggesting the poll file operation to be like below? > > static __poll_t iommufd_fault_fops_poll(struct file *filep, >                                         struct poll_table_struct *wait) > { >         struct iommufd_fault *fault = filep->private_data; >         __poll_t pollflags = EPOLLOUT; > >         poll_wait(filep, &fault->wait_queue, wait); >         mutex_lock(&fault->mutex); >         if (!list_empty(&fault->deliver)) >                 pollflags = EPOLLIN | EPOLLRDNORM; If I understood it correctly, here it should be, pollflags |= EPOLLIN | EPOLLRDNORM; >         mutex_unlock(&fault->mutex); > >         return pollflags; > } Best regards, baolu