vmt(4) refactoring time synchronization

[Takehiko NOZAKI]

implement vmbackdoor synctime.period is bit tricky

enable/disable vmware-tools synchronizing host ↔︎ guest time uses following RPC call:

Set_Option synctime <boolean>

and controls interval period’s RPC call:

Set_Option synctime.period <integer>

if synctime.period less or equal zero, assume default value(=60).

but vmt(4)'s sysctl(7) mib is slight differ.

machdep.vmt0.clock_sync.period = 60

if machdep.vmt0.clock_sync.period less or equal zero, disable time synchronization.

so that one sysctl(7) mib may fire two different async guest ->host RPC calls, also two async host → guest RPC calls changes one sysctl(7) mib. can i avoid race condition? maybe no.

[Takehiko NOZAKI]

one more, vmt(4)'s attach/detach raise three kernel thread by callout(9):

        callout_init(&sc->sc_tick, 0);
        callout_init(&sc->sc_tclo_tick, 0);
        callout_init(&sc->sc_clock_sync_tick, 0);

• sc_tick is main thread reflect guest information to host(guest's hostname, OS name and uptime)
• sc_tclo_tick is watchdog thread that recieve host -> guest RPC call
• sc_clock_sync_tick is host -> guest time synchronization thread

these all three threads has no parent/child relationship.

but if sc_tclo_tick thead recieved synctime.period RPC call, i have to halt/re-schedule sc_clock_sync_ticktthread, but sc_tclo_tick don’t know sc_clock_sync_tickt is started or not.

‌

sc_tclo_tick recieves host → guest’s RPC very early stage when sc_clock_sync_tickt may not started.

‌

yes i can flag struct vmt_softc whether sc_clock_sync_tickt is started and mutex any resource, but i don’t like it.

[Takehiko NOZAKI]

done <<cset:1728f3a840607651cbd165eedb5e5b9b99cd1034>>

[Takehiko NOZAKI]

to keep compatibility, sysctl’s behavior not changed.