From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9560926F296; Mon, 20 Oct 2025 16:03:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760976187; cv=none; b=VHhK4/25ciq1HFTD8M/gJJ4eMsYrCzI1AuE/5aVd5VmuURE1BlqeU9rW/bvGMCTBo4cTn3UGw/fXTZ0ncf8pgnvGfu/l7svWxkiDqM4z37ewm1qdx5wbbGtOl0b/CGPUqJVWx22YcvE+Xv0YZA31yO4CbGc9lWlj9z2lXQ0PmP0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760976187; c=relaxed/simple; bh=JvOCR57DWSFecee/oWHPQq1FBVtq9nwuQUxNx7n/1Hc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QV7eMiyw1ZLaMlfu7lX4ARcFcmkSro4qVH92+CLhO7wFmr7JKN5SJlXEi3dB6PChCHeYKPxl7rkv98XaPgXKoSPait+ZI/aueyf5pwTHoeQdKWvaMwJSmR/SgZiVHnGHoqitQ8zVeAmaq03UZCCjApz5mEh2fb6B9MX8p8/cC+4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=Le4Rme1q; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="Le4Rme1q" Received: from [10.0.0.114] (c-67-182-156-199.hsd1.wa.comcast.net [67.182.156.199]) by linux.microsoft.com (Postfix) with ESMTPSA id ADD68201DAC4; Mon, 20 Oct 2025 09:03:05 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com ADD68201DAC4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1760976185; bh=scyb7wZ7MdJMCaaNB+EvmDsakq25Zch1vo2shBY/s6Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Le4Rme1qvxnweUnpgb85Vv2YhukqWFRffwZc6f0b8/nUIThLnILtPvi/4Z+f8Z19s IZN+TkJ9H4AWwcNNYLs+zyB4bzLU9DjUtQfXcjHpRsvA8v10vnf6/yvgWuKu/Xq1YD PbVvr4e/1z8G4g2NMx6RXEgQocq7bTSJvHLr8KOE= Message-ID: Date: Mon, 20 Oct 2025 09:02:55 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mshv: Fix deposit memory in MSHV_ROOT_HVCALL To: Wei Liu Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, mhklinux@outlook.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, arnd@arndb.de, mrathor@linux.microsoft.com, skinsburskii@linux.microsoft.com References: <1760727497-21158-1-git-send-email-nunodasneves@linux.microsoft.com> <20251017220655.GA614927@liuwe-devbox-debian-v2.local> <20251017222633.GA632885@liuwe-devbox-debian-v2.local> Content-Language: en-US From: Nuno Das Neves In-Reply-To: <20251017222633.GA632885@liuwe-devbox-debian-v2.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10/17/2025 3:26 PM, Wei Liu wrote: > On Fri, Oct 17, 2025 at 10:06:55PM +0000, Wei Liu wrote: >> On Fri, Oct 17, 2025 at 11:58:17AM -0700, Nuno Das Neves wrote: >>> When the MSHV_ROOT_HVCALL ioctl is executing a hypercall, and gets >>> HV_STATUS_INSUFFICIENT_MEMORY, it deposits memory and then returns >>> -EAGAIN to userspace. The expectation is that the VMM will retry. >>> >>> However, some VMM code in the wild doesn't do this and simply fails. >>> Rather than force the VMM to retry, change the ioctl to deposit >>> memory on demand and immediately retry the hypercall as is done with >>> all the other hypercall helper functions. >>> >>> In addition to making the ioctl easier to use, removing the need for >>> multiple syscalls improves performance. >>> >>> There is a complication: unlike the other hypercall helper functions, >>> in MSHV_ROOT_HVCALL the input is opaque to the kernel. This is >>> problematic for rep hypercalls, because the next part of the input >>> list can't be copied on each loop after depositing pages (this was >>> the original reason for returning -EAGAIN in this case). >>> >>> Introduce hv_do_rep_hypercall_ex(), which adds a 'rep_start' >>> parameter. This solves the issue, allowing the deposit loop in >>> MSHV_ROOT_HVCALL to restart a rep hypercall after depositing pages >>> partway through. >>> >>> Signed-off-by: Nuno Das Neves >> >> In v1 you said you will add a "Fixes" tag. Where is it? > > I added this: > > Fixes: 621191d709b1 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") > > Let me know if that's not correct. > Oops! That's correct, thanks. > Wei