netdev - Re: [RFC PATCH 1/2] ptp: add PTP_SYS_OFFSET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ae5hdnhewksv2wkshxyyt3262mqi6o45opkl4occ5nt5zidr5e@lii7fgucetvu>
Date: Mon, 6 Jan 2025 18:46:17 +0100
From: Peter Hilber <quic_philber@...cinc.com>
To: Richard Cochran <richardcochran@...il.com>
CC: <linux-kernel@...r.kernel.org>, <virtualization@...ts.linux.dev>,
        <virtio-dev@...ts.linux.dev>, <netdev@...r.kernel.org>,
        Trilok Soni
	<quic_tsoni@...cinc.com>,
        Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eugenio Pérez
	<eperezma@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Andrew Lunn
	<andrew+netdev@...n.ch>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>,
        Jason Wang <jasowang@...hat.com>, Paolo Abeni
	<pabeni@...hat.com>,
        Shuah Khan <shuah@...nel.org>, Xuan Zhuo
	<xuanzhuo@...ux.alibaba.com>,
        <linux-kselftest@...r.kernel.org>, <linux-api@...r.kernel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        "Ridoux,
 Julien" <ridouxj@...zon.com>,
        John Stultz <jstultz@...gle.com>,
        "Thomas
 Gleixner" <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        "Anna-Maria
 Behnsen" <anna-maria@...utronix.de>
Subject: Re: [RFC PATCH 1/2] ptp: add PTP_SYS_OFFSET_STAT for xtstamping with
 status

On Thu, Jan 02, 2025 at 08:21:11AM -0800, Richard Cochran wrote:
> On Thu, Jan 02, 2025 at 05:11:01PM +0100, Peter Hilber wrote:
> > For sure. But the aim of this proposal is to have an interoperable time
> > synchronization solution for VMs through a Virtio device. So the idea is
> > to include metrics, if a consensus on their usefulness can be reached.
> > AFAIU it is difficult to bypass the kernel for Virtio devices.
> 
> Providing clock metrics only makes sense when there is some choice to
> be made based on those metrics.  If the "limited" VM guests don't even
> have networking, then they have no choice but to accept the time from
> the VM host, right?  In which case, the metrics do not provide any
> benefit to the guest.
> 
> Or what am I missing?

The proposal is not limited to guests with no networking.

Guests *might* not have internet access (might not be "internetworked").
Even then, guests can still interact with the environment (so metrics
can be important) and might decide to reduce features when the metrics
are too bad.

Thanks for the comments,

Peter