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 5B2DE2D9EC2; Thu, 19 Feb 2026 21:46:14 +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=1771537575; cv=none; b=p1eaeK7iFOlXzuFr6srarw0aE8I2DIJ44ds/hJIvE2DQhmWQOKGycRSBQ3nZUuXHCMC/gI3yehC2VncJqVIydUdb1TcxiW2wSjn6Pa5VDKN2L5SNVfBp3ykgoD4QQRMboyB+0yWrnfnKL8KwQz2FxtdCCqjme64sV9FonVn/po4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771537575; c=relaxed/simple; bh=chAvArdb7zpbFw83ywWlGpMZQLSe7yffb2J8O93YzZ4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YsgWm258dRd3Jm526ZD3Rn7xYXf95egpUxf1kVjv7JGlK7bd6maaOSFt04F1gat4/K1n2xdjh93y+cl5dJNebM/pLpeTs/HfFBmVTDI6SDguJyU/noJhF9RecAcX5AK6upH1Vu+/rkhcsNPxaBXY32NRC2FRrJgeVekLXHYP7Js= 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=ZRU6XyWJ; 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="ZRU6XyWJ" Received: from skinsburskii.localdomain (unknown [52.148.140.42]) by linux.microsoft.com (Postfix) with ESMTPSA id E762420B6F00; Thu, 19 Feb 2026 13:46:07 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E762420B6F00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1771537568; bh=aiuSqVkPHKzz0DSvSp7aacmsoZM2HA5BICGuqa562Wk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZRU6XyWJyHS3N0enA/8yyAp7k4D4JyIsLDdzlCobDzr32i6Z0hhs46zD0FIPXrV2u pC4hY20UmRkkb2TErTyLcC1T3ezwXsOvJpXm15/J7ydUDY25jN09ucR4PfYtJcg7ED n+13usEHr0tE29Zotj/6eeJkWScshdcx24sLOpNU= Date: Thu, 19 Feb 2026 13:46:05 -0800 From: Stanislav Kinsburskii To: Wei Liu Cc: Michael Kelley , "kys@microsoft.com" , "haiyangz@microsoft.com" , "decui@microsoft.com" , "longli@microsoft.com" , "linux-hyperv@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 4/4] mshv: Handle insufficient root memory hypervisor statuses Message-ID: References: <177031674698.186911.179832109354647364.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net> <177031694699.186911.12873334535011325477.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net> <20260219064701.GQ2236050@liuwe-devbox-debian-v2.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260219064701.GQ2236050@liuwe-devbox-debian-v2.local> On Thu, Feb 19, 2026 at 06:47:01AM +0000, Wei Liu wrote: > On Fri, Feb 06, 2026 at 06:54:55PM +0000, Michael Kelley wrote: > > From: Stanislav Kinsburskii Sent: Thursday, February 5, 2026 10:42 AM > > > To: kys@microsoft.com; haiyangz@microsoft.com; wei.liu@kernel.org; > > > decui@microsoft.com; longli@microsoft.com > > > Cc: linux-hyperv@vger.kernel.org; linux-kernel@vger.kernel.org > > > Subject: [PATCH v3 4/4] mshv: Handle insufficient root memory hypervisor statuses > > > > > > When creating guest partition objects, the hypervisor may fail to > > > allocate root partition pages and return an insufficient memory status. > > > In this case, deposit memory using the root partition ID instead. > > > > > > Note: This error should never occur in a guest of L1VH partition context. > > > > > > Signed-off-by: Stanislav Kinsburskii > > > --- > > > drivers/hv/hv_common.c | 2 + > > > drivers/hv/hv_proc.c | 14 ++++++++++ > > > include/hyperv/hvgdk_mini.h | 58 ++++++++++++++++++++++--------------------- > > > 3 files changed, 46 insertions(+), 28 deletions(-) > > > > > > diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c > > > index f20596276662..6b67ac616789 100644 > > > --- a/drivers/hv/hv_common.c > > > +++ b/drivers/hv/hv_common.c > > > @@ -794,6 +794,8 @@ static const struct hv_status_info hv_status_infos[] = { > > > _STATUS_INFO(HV_STATUS_PROPERTY_VALUE_OUT_OF_RANGE, -EIO), > > > _STATUS_INFO(HV_STATUS_INSUFFICIENT_MEMORY, -ENOMEM), > > > _STATUS_INFO(HV_STATUS_INSUFFICIENT_CONTIGUOUS_MEMORY, -ENOMEM), > > > + _STATUS_INFO(HV_STATUS_INSUFFICIENT_ROOT_MEMORY, -ENOMEM), > > > + _STATUS_INFO(HV_STATUS_INSUFFICIENT_CONTIGUOUS_ROOT_MEMORY, -ENOMEM), > > > _STATUS_INFO(HV_STATUS_INVALID_PARTITION_ID, -EINVAL), > > > _STATUS_INFO(HV_STATUS_INVALID_VP_INDEX, -EINVAL), > > > _STATUS_INFO(HV_STATUS_NOT_FOUND, -EIO), > > > diff --git a/drivers/hv/hv_proc.c b/drivers/hv/hv_proc.c > > > index 181f6d02bce3..5f4fd9c3231c 100644 > > > --- a/drivers/hv/hv_proc.c > > > +++ b/drivers/hv/hv_proc.c > > > @@ -121,6 +121,18 @@ int hv_deposit_memory_node(int node, u64 partition_id, > > > case HV_STATUS_INSUFFICIENT_CONTIGUOUS_MEMORY: > > > num_pages = HV_MAX_CONTIGUOUS_ALLOCATION_PAGES; > > > break; > > > + > > > + case HV_STATUS_INSUFFICIENT_CONTIGUOUS_ROOT_MEMORY: > > > + num_pages = HV_MAX_CONTIGUOUS_ALLOCATION_PAGES; > > > + fallthrough; > > > + case HV_STATUS_INSUFFICIENT_ROOT_MEMORY: > > > + if (!hv_root_partition()) { > > > + hv_status_err(hv_status, "Unexpected root memory deposit\n"); > > > + return -ENOMEM; > > > + } > > > + partition_id = HV_PARTITION_ID_SELF; > > > + break; > > > + > > > > Per the discussion in v1 of this patch set, if the number of pages that should be > > deposited in a particular situation is different from what this function provides, > > the fallback is to use hv_call_deposit_pages() directly. From what I see, there's > > only one such fallback case after a hypercall failure -- in hv_do_map_gpa_hcall(). > > The other uses of hv_call_deposit_pages() are initial deposits when creating a > > VP or partition. > > > > But if hv_call_deposit_pages() is used directly, the logic added here to detect > > insufficient root memory and deposit to HV_PARTITION_ID_SELF isn't applied. > > So if the hypercall in hv_do_map_gpa_hcall() fails with insufficient root > > memory, the deposit is done to the wrong partition ID. If that case can > > actually happen, then some additional logic is needed in > > hv_do_map_gpa_hcall() to handle it. Or there needs to be a fallback > > function that contains the logic. > > Stanislav, how about this comment? Please submit a follow-up patch if > necessary. > I'll sumbit a follow-up patch. Thanks, Stanislav > Wei > > > > > Other than that, everything else in this patch set looks good to me. > > > > Michael > > > > > default: > > > hv_status_err(hv_status, "Unexpected!\n"); > > > return -ENOMEM;