From: Richard Cochran <richardcochran@gmail.com>
To: Peter Hilber <quic_philber@quicinc.com>
Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux.dev,
virtio-dev@lists.linux.dev, netdev@vger.kernel.org,
"Trilok Soni" <quic_tsoni@quicinc.com>,
"Srivatsa Vaddagiri" <quic_svaddagi@quicinc.com>,
"David S. Miller" <davem@davemloft.net>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Jason Wang" <jasowang@redhat.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"Shuah Khan" <shuah@kernel.org>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
linux-kselftest@vger.kernel.org, linux-api@vger.kernel.org,
"David Woodhouse" <dwmw2@infradead.org>,
"Ridoux, Julien" <ridouxj@amazon.com>,
"John Stultz" <jstultz@google.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Stephen Boyd" <sboyd@kernel.org>,
"Anna-Maria Behnsen" <anna-maria@linutronix.de>
Subject: Re: [RFC PATCH 1/2] ptp: add PTP_SYS_OFFSET_STAT for xtstamping with status
Date: Wed, 25 Dec 2024 16:42:14 -0800 [thread overview]
Message-ID: <Z2ymZuiFqY8mxihJ@hoboy.vegasvil.org> (raw)
In-Reply-To: <wcxdbqhoe4cppukyy5rvkq5am4ht6wk5u6d6g2k2swqhidjw7i@6nar5vuusm35>
On Mon, Dec 23, 2024 at 07:13:46PM +0100, Peter Hilber wrote:
> The precise synchronization of the VM guest with its immediate
> environment can also be important; a VM guest may depend the decision
> about leap second smearing on its environment.
I thought that the whole point of using a VM is to isolate the guests
from each other and the host. What you describe is a promiscuous
coupling between guest and host, and the kernel shouldn't be in
the business of supporting such behavior.
> Also, the administrative
> configuration choice may change over the lifetime of a system.
Right, which is why we should keep those choices out of kernel space.
Kernel provides mechanism, not policy.
> The intent is to also support (embedded) VM clients which are themselves
> not necessarily internetworked, which do not get a lot of maintenance,
> and which are not guaranteed to get an update within the typically less
> than 6 months between leap second announcement and occurrence.
Again, I don't think the kernel should be the solution to guests that
lack networking. Instead, the place to fix the problem is at the
root, namely in the guests.
> I agree that a device driver should not determine clock quality metrics.
> The intent is that the driver forwards metrics, if such are advertised
> by the device. These metrics should describe the accuracy etc. of the
> device itself.
Overall, I don't trust devices to tell the truth about their
qualities. But putting that aside, we would need to see some kind of
commonality in hardware implementation to advertise their metrics.
However, AFAICT there is no such industry practice on the market.
> The patch message should document this more clearly. The
> metrics can be determined e.g. by virtualization host user space
> software. The device driver would just expose the device metrics to user
> space.
Again, host user space shouldn't misuse the kernel to share random
metrics with guest user space. Isn't there another way to share such
info from host to guest?
Thanks,
Richard
next prev parent reply other threads:[~2024-12-26 0:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 20:42 [RFC PATCH 0/2] ptp: add PTP_SYS_OFFSET_STAT ioctl, support it in virtio_rtc Peter Hilber
2024-12-19 20:42 ` [RFC PATCH 1/2] ptp: add PTP_SYS_OFFSET_STAT for xtstamping with status Peter Hilber
2024-12-20 15:19 ` Richard Cochran
2024-12-23 18:13 ` Peter Hilber
2024-12-26 0:42 ` Richard Cochran [this message]
2025-01-02 16:11 ` Peter Hilber
2025-01-02 16:21 ` Richard Cochran
2025-01-06 17:46 ` Peter Hilber
2024-12-19 20:42 ` [RFC PATCH 2/2] virtio_rtc: Support PTP_SYS_OFFSET_STAT ioctl Peter Hilber
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=Z2ymZuiFqY8mxihJ@hoboy.vegasvil.org \
--to=richardcochran@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=anna-maria@linutronix.de \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=jstultz@google.com \
--cc=kuba@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_philber@quicinc.com \
--cc=quic_svaddagi@quicinc.com \
--cc=quic_tsoni@quicinc.com \
--cc=ridouxj@amazon.com \
--cc=sboyd@kernel.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=virtio-dev@lists.linux.dev \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/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