netdev - Re: PHC device sharing between PCI functions

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]

Date:	Fri, 5 Jul 2013 07:25:48 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	linux-net-drivers <linux-net-drivers@...arflare.com>,
	netdev <netdev@...r.kernel.org>,
	Laurence Evans <levans@...arflare.com>
Subject: Re: PHC device sharing between PCI functions

On Thu, Jul 04, 2013 at 07:19:05PM +0100, Ben Hutchings wrote:

> The functions that are intended to be assigned to guests will still
> appear and may have a driver bound to them in the host before they are
> assigned to guests.

Okay, then to answer your question...

> On Thu, 2013-07-04 at 19:39 +0200, Richard Cochran wrote:
> > On Thu, Jul 04, 2013 at 05:21:18PM +0100, Ben Hutchings wrote:
> > > 
> > > But that is the opposite of what we're talking about.  Say the card has,
> > > 16 functions resulting in net devices eth0-eth15, each of which can
> > > access the same physical clock.  You said it's OK to have read-only
> > > aliases for a clock, so then there might be a writable /dev/ptp0 and
> > > read-only /dev/ptp1-ptp15.  What is the proper association between net
> > > devices and clock devices?

I would say simply:

	ethtool -T eth0  -> phc index 0  RDWR
	ethtool -T eth1  -> phc index 1  RDONLY
	...
	ethtool -T eth15 -> phc index 15 RDONLY

The numbering might come out differently, but it should be 1:1.

The userland PTP stack will just have to be configured to make sense
of this. For example, the host can just use eth0/ptp0 normally. For
the guests, in ptp4l we have a "free_running" option that leaves the
clock alone and just calculates phase and frequency offset.

Local applications can use this information to synchronize to the
remote master. (BTW this method is specified by 802.1AS). Also, you
can discipline the system clock by measuring the sys-phc offset and
adding the phc-master offset.

If the clocks set their .max_adj to zero, then the fact that they are
read only is discoverable.

Thanks,
Richard

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html