Re: PHC device sharing between PCI functions

[Richard Cochran <richardcochran@gmail.com>]

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