public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Chen Yu <yu.c.chen@intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-acpi@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	linux-kernel@vger.kernel.org, Ashok Raj <ashok.raj@intel.com>,
	Andy Shevchenko <andriy.shevchenko@intel.com>,
	Mike Rapoport <rppt@kernel.org>, Aubrey Li <aubrey.li@intel.com>
Subject: Re: [PATCH v4 3/4] drivers/acpi: Introduce Platform Firmware Runtime Update Telemetry
Date: Wed, 20 Oct 2021 16:29:39 +0800	[thread overview]
Message-ID: <20211020082939.GA44221@chenyu-desktop> (raw)
In-Reply-To: <YWrrYWeW7uaiJ51u@kroah.com>

On Sat, Oct 16, 2021 at 05:10:25PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Oct 16, 2021 at 06:44:31PM +0800, Chen Yu wrote:
> > Platform Firmware Runtime Update(PFRU) Telemetry Service is part of RoT
> > (Root of Trust), which allows PFRU handler and other PFRU drivers to
> > produce telemetry data to upper layer OS consumer at runtime.
> > 
> > The linux provides interfaces for the user to query the parameters of
> > telemetry data, and the user could read out the telemetry data
> > accordingly.
> 
> What type of interface is this?  How does userspace interact with it?
> 
> > 
> > Also add the ABI documentation.
> 
> Add it where?
>
They are all ioctl interfaces, and was introduced in previous patch in
Documentation/ABI/testing/pfru. The way userspace interace with it is
introduced in next patch in the man page. I'll revise the commit log to
better describe how user could use it.
> > 
> > Typical log looks like:
> > [SmmRuntimeUpdateHandler.ProcessSmmRuntimeUpdate]
> > ProcessSmmRuntimeUpdate = START, Action = 2
> > [SmmRuntimeUpdateHandler.ProcessSmmRuntimeUpdate]
> > FwVersion = 0, CodeInjectionVersion = 1
> > [ShadowSmmRuntimeUpdateImage]
> > Image = 0x74D9B000, ImageSize = 0x1172
> > [ProcessSmmRuntimeUpdate]
> > ShadowSmmRuntimeUpdateImage.Status = Success
> > [ValidateSmmRuntimeUpdateImage]
> > CapsuleHeader.CapsuleGuid = 6DCBD5ED-E82D-4C44-BDA1-7194199AD92A
> > [ValidateSmmRuntimeUpdateImage]
> > FmpCapHeader.Version = 1
> > [ValidateSmmRuntimeUpdateImage]
> > FmpCapImageHeader.UpdateImageTypeId = B2F84B79-7B6E-4E45-885F-3FB9BB185402
> > [ValidateSmmRuntimeUpdateImage]
> > SmmRuntimeUpdateVerifyImageWithDenylist.Status = Success
> > [ValidateSmmRuntimeUpdateImage]
> > SmmRuntimeUpdateVerifyImageWithAllowlist.Status = Success
> > [SmmCodeInjectionVerifyPayloadHeader]
> > PayloadHeader.Signature = 0x31494353
> > [SmmCodeInjectionVerifyPayloadHeader]
> > PayloadHeader.PlatformId = 63462139-A8B1-AA4E-9024-F2BB53EA4723
> > [SmmCodeInjectionVerifyPayloadHeader]
> > PayloadHeader.SupportedSmmFirmwareVersion = 0,
> > PayloadHeader.SmmCodeInjectionRuntimeVersion = 1
> > [ProcessSmmRuntimeUpdate]
> > ValidateSmmRuntimeUpdateImage.Status = Success
> > CPU CSR[0B102D28] Before = 7FBF830E
> > CPU CSR[0B102D28] After = 7FBF8310
> > [ProcessSmmRuntimeUpdate] ProcessSmmCodeInjection.Status = Success
> > [SmmRuntimeUpdateHandler.ProcessSmmRuntimeUpdate]
> > ProcessSmmRuntimeUpdate = End, Status = Success
> 
> This log does not make any sense to me, where is it from?  Why the odd
> line-wrapping?
>
It is from the telemetry log generated by the BIOS. Since this content is
platform specific, I'll remove the log in next version.
> > +};
> > +
> > +
[snip...]
> > +ssize_t pfru_log_read(struct file *filp, char __user *ubuf,
> > +		      size_t size, loff_t *off)
> > +{
> > +	struct pfru_log_data_info info;
> > +	phys_addr_t base_addr;
> > +	int buf_size, ret;
> > +	char *buf_ptr;
> > +
> > +	if (!pfru_log_dev)
> > +		return -ENODEV;
> > +
> > +	if (*off < 0)
> > +		return -EINVAL;
> > +
> > +	ret = get_pfru_log_data_info(&info, pfru_log_dev->info.log_type);
> > +	if (ret)
> > +		return ret;
> > +
> > +	base_addr = (phys_addr_t)(info.chunk2_addr_lo | (info.chunk2_addr_hi << 32));
> > +	/* pfru update has not been launched yet.*/
> > +	if (!base_addr)
> > +		return -EBUSY;
> > +
> > +	buf_size = info.max_data_size;
> > +	if (*off >= buf_size)
> > +		return 0;
> > +
> > +	buf_ptr = memremap(base_addr, buf_size, MEMREMAP_WB);
> > +	if (IS_ERR(buf_ptr))
> > +		return PTR_ERR(buf_ptr);
> > +
> > +	size = min_t(size_t, size, buf_size - *off);
> > +	if (copy_to_user(ubuf, buf_ptr + *off, size))
> > +		ret = -EFAULT;
> > +	else
> > +		ret = 0;
> 
> As all you are doing is mapping some memory and reading from it, why do
> you need a read() file operation at all?  Why not just use mmap?
> 
In the beginning mmap() interface was provided to the user. Then it was
realized that there is no guarantee in the spec that, the physical address
provided by the BIOS would remain unchanged. So instead of asking the user
to mmap the file each time before reading the log, the read() is leveraged
here to always memremap() the latest address.

thanks,
Chenyu
> thanks,
> 
> greg k-h

  reply	other threads:[~2021-10-20  8:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-16 10:26 [PATCH v4 0/4] Introduce Platform Firmware Runtime Update and Telemetry drivers Chen Yu
2021-10-16 10:31 ` [PATCH v4 1/4] efi: Introduce EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER and corresponding structures Chen Yu
2021-10-16 10:40 ` [PATCH v4 2/4] drivers/acpi: Introduce Platform Firmware Runtime Update device driver Chen Yu
2021-10-16 15:16   ` Greg Kroah-Hartman
2021-10-19 16:33     ` Rafael J. Wysocki
2021-10-20  8:00     ` Chen Yu
2021-10-16 10:44 ` [PATCH v4 3/4] drivers/acpi: Introduce Platform Firmware Runtime Update Telemetry Chen Yu
2021-10-16 15:10   ` Greg Kroah-Hartman
2021-10-20  8:29     ` Chen Yu [this message]
2021-10-20  8:27       ` Greg Kroah-Hartman
2021-10-20  8:53         ` Mike Rapoport
2021-10-20  9:17         ` Chen Yu
2021-10-21  6:37   ` kernel test robot
2021-10-16 10:47 ` [PATCH v4 4/4] tools: Introduce power/acpi/pfru/pfru Chen Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211020082939.GA44221@chenyu-desktop \
    --to=yu.c.chen@intel.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=ardb@kernel.org \
    --cc=ashok.raj@intel.com \
    --cc=aubrey.li@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rppt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox