In D59997#1377152, @imp wrote:

This looks good, but wondering how well we know time at mountroot(). For most platforms likely "pretty good" but there's some w/o rtc that could support nvme drives that might end up setting the wrong time. Is that acceptable here?

I tested this on AMD64 only for now, i will try this weekend on ARM(apple), then on RPI5.

Right now i'm just trying to understand the NVME v2.4 and implement what i can test here.
risky changes are postponed and Edge cases are welcome to know.

Are you aware of any platform without RTC ?

In D59997#1377343, @seuros wrote:

In D59997#1377152, @imp wrote:

This looks good, but wondering how well we know time at mountroot(). For most platforms likely "pretty good" but there's some w/o rtc that could support nvme drives that might end up setting the wrong time. Is that acceptable here?

I tested this on AMD64 only for now, i will try this weekend on ARM(apple), then on RPI5.

Right now i'm just trying to understand the NVME v2.4 and implement what i can test here.
risky changes are postponed and Edge cases are welcome to know.

Are you aware of any platform without RTC ?

IIRC, some RPi models, though I don't know if it's the PCI-capable ones or not. Some of the rockchip boards. At least some of these don't have ToD RTC that survive reboot and/or power cycle.

IIRC, some RPi models, though I don't know if it's the PCI-capable ones or not. Some of the rockchip boards. At least some of these don't have ToD RTC that survive reboot and/or power cycle.

i will check with @martinfilla_post.cz and @adrian before landing this one.

In D59997#1377349, @seuros wrote:

IIRC, some RPi models, though I don't know if it's the PCI-capable ones or not. Some of the rockchip boards. At least some of these don't have ToD RTC that survive reboot and/or power cycle.

i will check with @martinfilla_post.cz and @adrian before landing this one.

I wonder if we shouldn't create a 'time stepped' event and use that maybe as a fallback? We might even have one, I haven't checked.

In D59997#1377348, @imp wrote:

In D59997#1377343, @seuros wrote:

In D59997#1377152, @imp wrote:

This looks good, but wondering how well we know time at mountroot(). For most platforms likely "pretty good" but there's some w/o rtc that could support nvme drives that might end up setting the wrong time. Is that acceptable here?

I tested this on AMD64 only for now, i will try this weekend on ARM(apple), then on RPI5.

Right now i'm just trying to understand the NVME v2.4 and implement what i can test here.
risky changes are postponed and Edge cases are welcome to know.

Are you aware of any platform without RTC ?

IIRC, some RPi models, though I don't know if it's the PCI-capable ones or not. Some of the rockchip boards. At least some of these don't have ToD RTC that survive reboot and/or power cycle.

The RPi Zero (which we don't support; it's an arm32--armv7l--platform) might fall under this category according to some quick poking around /sys/class/rtc on my RPi Zero board using Raspbian 12 (has a 6.12-based kernel). It's a really basic board, so this probably wouldn't impact it, as @imp suspected.
Do we support (or have plans to support) NVMe over thunderbolt or lower bandwidth USB? If so, I can see that being a future potential problem (even for platforms that lack PCI support).
I wonder if there's a way to query the controller to determine whether or not RTC support is available.

One quick ask: please allow this support to be disabled via a kernel sysctl/tunable. While I don't suspect this will be the bulk majority of hosts/users, having something to turn off if it turns out is completely broken on a platform would be helpful to avoid the case mentioned by @imp on non-supporting platforms. Even having this compilable out (but enabled by default) might be a good idea (hint to @seuros, just in case: this requires adding some build glue to sys/conf to use opt_ headers).

Do we support (or have plans to support) NVMe over thunderbolt or lower bandwidth USB? If so, I can see that being a future potential problem (even for platforms that lack PCI support).

We don't support it yet. But we should support it.

I have 1 enclosure that support TB4 speed , but only macOS currently use it.

I think we could refactor the nvme driver later, it still missing lot of plumbing.

Does the specification actually talk about what it uses it for? And can you change it during normal operation?

eg, what if the time it got was plainly wrong (not that there's no RTC, but the RTC is very very wrong) and it takes an ntpdate/ntpd trip to get it up to date.
What should the driver / controller do in this instance?

In D59997#1377731, @adrian wrote:

Does the specification actually talk about what it uses it for? And can you change it during normal operation?

eg, what if the time it got was plainly wrong (not that there's no RTC, but the RTC is very very wrong) and it takes an ntpdate/ntpd trip to get it up to date.
What should the driver / controller do in this instance?

Timestamp values should not be used for security applications. Other application use of the Timestamp feature is outside the scope of this specification.

This Feature enables the host to set a timestamp value in the controller. The Timestamp field value in a Set Features command sets a timestamp value in the controller. After the current value for this Feature is set, the controller updates that value as time passes.

The feature is simple, the host gives the RTC to the controller of the NVME. The NVME use that switch to that time in it log.
If you have UART connected to the nvme, (you need to use 1.8v) , you will see the time switching from tick to date.
If the kernel panic, wedge or enter in the debugger. You can still fetch timestamped logs from the NVME with the correct time.
If the NVME enter a state (sleep or shutdown) , it log internally the time of the event.

Some NVME have Temu grade controller and did not implement this feature, but they still handle this hook then ignore it.

There are plenty of gaps left in the driver.

I'd kinda hoped this would have had the timestamp issues I raised before the commit taken care of.
It's likely best resolved at this point with a sysctl that just sets the time, at a minimum to cover the gap.