From nobody Mon May 17 20:27:49 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 176A285FD61 for ; Mon, 17 May 2021 20:27:58 +0000 (UTC) (envelope-from junguk.kim@gmail.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkW0Y711wz3ktv for ; Mon, 17 May 2021 20:27:57 +0000 (UTC) (envelope-from junguk.kim@gmail.com) Received: by mail-qt1-x833.google.com with SMTP id i20so5617944qtx.4 for ; Mon, 17 May 2021 13:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=8jEIHbgT99ZxJiFVSxpful4/ssN+HfKIIt2wKHtcEpw=; b=oTKq/WTBwAHEtPh0SnOpxJE1fdLSmExC+l17EKz+vzqBKEY6EQTOgPXQk+MWMR24dU /j/yMfYggRMYaWGq7ahIfAji6KE9jXmm55sUKIXF/qVv5ndACPiBc2vOzOT0P/vnpDXl xQ/MyFOFjP6C3jzR+sb/KUU+6qTeiiXubEOLRce3P/9bV6ZrR67a/KtZI3ERuL1hmPnV 0el0lcjVtvLiD7WBniT2qtufAoBYJpHgVIRXkYZGn2pq/YenYybysQX/nv4Je3RnY1y/ TdDDDIJ5GkATqAGl3BVyKmX0p4ks6AzYTzVqQ6EWCdcNxEKT6Rm4Rpi7tb0Nwq43KvLk +rcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8jEIHbgT99ZxJiFVSxpful4/ssN+HfKIIt2wKHtcEpw=; b=DgSBA7lKcqgrR8ofjIe9zKSbZNCEZijMEWfw7Sp4DrQkp7WkJnv5JqOSsVlI8fRR69 yhIkuWs1qBdSPP3Rs5GzGPNpvBfRDNicyKJmG5Av39MouJwQNq9biFwjzYiunBqusf8n 2H9up/ALlKqorlJUosVZ+5vXhspVcwWXriElsKXG/Afx6XPZIy8fdnPutffpW9W7usDO s3WHmggtbup45+AzI59NtpXm7Qg0pMS0AmaVeeZUpTyHG8CqF1nh0uvhCkvspm7MX3zz PfHwDEJiRecLwaqvtnHRh0Z4j7XBrlNKNKNhrRQ/OltpkrnpU38Ee15zWewR8vDBShsq Ch6Q== X-Gm-Message-State: AOAM530+qMj0nTDvDzuK5weGW0dtmWjmDSoMoXKsNu5gniSRYvFdQohK jyy4VQH0JqQ+07rAwgeSQSdTql/CuP7J1A== X-Google-Smtp-Source: ABdhPJz1i2N9rDUw4PzOH4RgOgXCWSbUOMPKgrZdD1UIXhef7gQwFKDASUfMDvYyC+tfUANGSmX7pg== X-Received: by 2002:ac8:4b74:: with SMTP id g20mr1316168qts.196.1621283276716; Mon, 17 May 2021 13:27:56 -0700 (PDT) Received: from hammer.mj.niksun.com (pool-100-8-53-238.nwrknj.fios.verizon.net. [100.8.53.238]) by smtp.gmail.com with ESMTPSA id a16sm10852268qkl.46.2021.05.17.13.27.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 May 2021 13:27:56 -0700 (PDT) To: John Nielsen , "freebsd-acpi@freebsd.org" References: From: Jung-uk Kim Subject: Re: How to properly locate/parse ACPI table from kernel module? Message-ID: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> Date: Mon, 17 May 2021 16:27:49 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4FkW0Y711wz3ktv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] On 21. 5. 17., John Nielsen wrote: > Hi all- > > I’m not much of a kernel programmer but I’m trying to maintain/improve the isboot module, which allows booting directly from iSCSI by reading the iSCSI Boot Firmware Table (iBFT), bringing up the interface with the details specified therein and connecting to the specified iSCSI target before trying to mount root. > > I’m not the original author but as the port maintainer I am hosting the code here: https://github.com/jnielsendotnet/isboot > > I have a test system where the module loads but fails to find the iBFT. I reviewed the iBFT code and realized it has a bunch of magic numbers mixed in with some random memory diving. If I’m reading it right (see https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 and https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521), it looks like it scans all of the (kernel?) memory between 512K and 1M in 16-byte increments looking for one beginning with the string “iBFT”, which if it finds will be used as the offset for reading the table. I don’t know where the 512K and 1M values came from or if they are correct, but I do have a system where that method does not work. > > IIUC, the iBFT is an ACPI table, and it seems like using ACPI to find it would be safer and more reliable. So my question is: how does one do that? Are there other places in the kernel code that do this sort of thing that I could use as a model? Any gotchas I should know about as a (less-than) novice kernel programmer? You may use AcpiGetTable() and AcpiPutTable(), e.g., status = AcpiGetTable(ACPI_SIG_IBFT, ...); Jung-uk Kim