From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web08.2958.1660574551053971952 for ; Mon, 15 Aug 2022 07:42:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ELgPnjgW; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 88F9360FCE for ; Mon, 15 Aug 2022 14:42:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 578FEC433C1 for ; Mon, 15 Aug 2022 14:42:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660574550; bh=3Sf2Krvu+bYf+fHrkk6UHOtcdpVO7OuPwHfIus5l5jo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ELgPnjgWfM7RFw1HDTrXwW0jqYEEZNO6247PoIWP16vIxOMkwtCPo/2OVAM8kK4cE bYmfOTu1ya2FPBE1TuKt26Jo2kksjnCOPAqaLy1XP7YRzsXARq6jp9WzHPD/Zrc0K2 7YqFV2r00vCrtfGHzbAY2oetugHuXlS5YzIjIuJS+y61eyUe+HvjK6eJu2/r1S4v0M jbJ6+h2hzeDLBTtloq+D7dun9C/wx80C7MGbPEVqY3BDqkFPXcftbL6TjTKQecXUpj JuEjTsMtkEAK0aAVk4XxRd34N5Aljq+su2AqxGAlEQwPfMO0W0DtWtMauX+dh9Q9Z9 BTTHNUdyZ5EqQ== Received: by mail-wm1-f43.google.com with SMTP id p12-20020a7bcc8c000000b003a5360f218fso7899269wma.3 for ; Mon, 15 Aug 2022 07:42:30 -0700 (PDT) X-Gm-Message-State: ACgBeo2uQvABUj0rCYZIa7sOZE2F4LC1go31rCOxsiRo2i/geV+Cgls5 /ACjy4/qhhyxp/OLgANFBqhBl+Fr3pOVusW4TWc= X-Google-Smtp-Source: AA6agR7Ti6Mu3sG03XBkM58KtMKjYNwatTU+ruvQagnKhQKEWUl+7qj5Aug+o8oSXIivsiw0rL+Q0U4GKGJW5Cm2EX8= X-Received: by 2002:a05:600c:a45:b0:3a4:d07e:112d with SMTP id c5-20020a05600c0a4500b003a4d07e112dmr10237574wmq.141.1660574548641; Mon, 15 Aug 2022 07:42:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 15 Aug 2022 16:42:17 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/NonDiscoverablePciDeviceDxe: Allow partial FreeBuffer To: devel@edk2.groups.io, jbrasen@nvidia.com Cc: "hao.a.wu@intel.com" , "ray.ni@intel.com" , "quic_llindhol@quicinc.com" , "ardb+tianocore@kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 5 Aug 2022 at 18:56, Jeff Brasen via groups.io wrote: > > > > > -----Original Message----- > > From: Ard Biesheuvel > > Sent: Tuesday, August 2, 2022 10:51 AM > > To: Jeff Brasen > > Cc: devel@edk2.groups.io; hao.a.wu@intel.com; ray.ni@intel.com; > > quic_llindhol@quicinc.com; ardb+tianocore@kernel.org > > Subject: Re: [PATCH v2] MdeModulePkg/NonDiscoverablePciDeviceDxe: > > Allow partial FreeBuffer > > > > External email: Use caution opening links or attachments > > > > > > On Tue, 2 Aug 2022 at 17:32, Jeff Brasen wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Ard Biesheuvel > > > > Sent: Friday, July 29, 2022 9:48 AM > > > > To: Jeff Brasen > > > > Cc: devel@edk2.groups.io; hao.a.wu@intel.com; ray.ni@intel.com; > > > > quic_llindhol@quicinc.com; ardb+tianocore@kernel.org > > > > Subject: Re: [PATCH v2] MdeModulePkg/NonDiscoverablePciDeviceDxe: > > > > Allow partial FreeBuffer > > > > > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > On Thu, 28 Jul 2022 at 13:25, Jeff Brasen wrot= e: > > > > > > > > > > > > > > > Adding Leif/Ard to CC incase they have any comments on this patch= . > > > > > > > > > > > > > This generally looks ok to me. I just wonder if it wouldn't be > > > > simpler to reuse the existing allocation descriptor if it is not > > > > being freed entirely. Given the [presumably] the most common case i= s > > > > to allocate and then free some pages at the end, lowering the page > > > > count on the existing descriptor would cover most cases, and we'd > > > > only need to allocate new ones if pages are being freed at the star= t or in > > the middle. > > > > > > There is often freeing at the beginning as well as this is being used= to create > > a 64K aligned section of memory in the case. So it over allocates and t= he > > free's some at the beginning and the end. I could probably make it dete= ct > > and use that but figured this code would support all cases and required= less > > case specific detection. > > > > > > > Ah interesting. Would it help if the allocate routine aligned allocatio= ns to their > > size? > > The PciIo->AllocateBuffer function doesn't support passing the request in= so we would need to know that info beforehand. The current calling in the = XHCI driver does a free at the beginning and then the end of the buffer so = we could the existing allocation tracker but figured it would be better to = correct the function just in case someone called it to free in the middle. > What I was wondering is whether such allocations are themselves multiples of 64k. This is perhaps orthogonal to the issue this patch addresses, as we'' still need to deal with partial free calls regardless. But I was curious whether XHCI in particular, and perhaps more generally, we could streamline this by aligning all allocations to a log2 upper bound of their sizes.