From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web11.131709.1598008793979730715 for ; Fri, 21 Aug 2020 04:19:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JGcFUO+m; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598008793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YmIViGnlzep1WECRmpKFBn5iMypFmxkqGqnB11c1CpI=; b=JGcFUO+mIGBlQQ5EwWpE6nv16w0+8LLWy6zOCnzcq1nKtLBJPQ28rxk9OaOs8w0Sr3Rca8 27n5xHrA2++IWWLTAw6xolXAuGljT91xoifunNsNW4ueUDOleM/SEt5VvnCsKJcf1orJL7 e1/Kj9+pWYlyHm1XGd7wW2hE8RGtS4c= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-334-uflM7MMvP1GsOZ_sD0afvw-1; Fri, 21 Aug 2020 07:19:49 -0400 X-MC-Unique: uflM7MMvP1GsOZ_sD0afvw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ECD20186A58F; Fri, 21 Aug 2020 11:19:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-164.ams2.redhat.com [10.36.113.164]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2605319C78; Fri, 21 Aug 2020 11:19:44 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow To: devel@edk2.groups.io, mcb30@ipxe.org, maciej.rabeda@linux.intel.com Cc: Jiaxin Wu , Siyuan Fu , Seven.ding@lcfuturecenter.com References: <20200819165338.681-1-maciej.rabeda@linux.intel.com> <2dde2087-e291-0232-62e2-a30cdf4e09b2@redhat.com> From: "Laszlo Ersek" Message-ID: <93ed808c-8414-310d-c065-36a92ebea2e7@redhat.com> Date: Fri, 21 Aug 2020 13:19:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/19/20 20:46, Michael Brown wrote: > On 19/08/2020 19:13, Laszlo Ersek wrote: >> I'm still undecided whether option#43 / tag#6 / bit#3 being clear means >> we should *ignore* PXE_BOOT_SERVERS (tag#8), but I'm willing to defer to >> you on that. So, I can give a cautious >> >> Reviewed-by: Laszlo Ersek >> >> for this patch. > > FWIW, iPXE's equivalent logic (based on a combination of what the PXE > spec says and what the Intel reference PXE implementation actually does, > which is not necessarily the same thing) is to *ignore* PXE_BOOT_SERVERS > if a DHCP filename is available and option 43 tag 6 bit 3 is *set*. Sorry, I expressed my concern incorrectly (I think I was tripped up by the typo in Maciej's commit message). It's about bit#2 in PXE_DISCOVERY_CONTROL. The question is whether bit#2 is *equivalent* to adhering to PXE_BOOT_SERVERS ("if, and only if"). When bit#2 is set, the spec says we must. OK. When bit#2 is clear, the spec doesn't say anything. So two interpretations are possible, "we still may consider PXE_BOOT_SERVERS", and "we must not consider PXE_BOOT_SERVERS". Anyway -- I'm sending this just to explain my earlier email. My main point remains: http://mid.mail-archive.com/11640b08-6f42-e4d8-356d-91d4bdf86c2c@redhat.com (alt link: https://edk2.groups.io/g/devel/message/64530) Thanks Laszlo