Call for testing bhyve cpu topology additions

[Peter Grehan]

> I shall iterate again, this change makes no change to what the guests
> sees if you use the old method sysctl hw.vmm.topology.cores_per_package
> or hw.vmm.topology.threads_per_core to set these values, it is
> purely a interface enhancement that makes these tuneables easy
> to access from userland bhyve(8).

  Those sysctls were an undocumented workaround with no error checking.

  You are making this a documented part of bhyve,

> A guest can not tell the diffence in what way these are set.
> If hw.vmm.topology.* needs testing thats not on me, that is
> an existing problem, and one that has existed for far too long.

  Ah, no, the testing is on you, not the user community.

>>    You can easily download an eval of Windows 10 to try this out with.
>> You do not (and have never) required ATA support to run Windows on bhyve.
> 
> I have made a call for testing, whats your issue?
> Are you trying to force me to do that testing?

  At a minimum, you are expected to test changes that you expect to commit.

> And I consider this change rather trivial and with near 0 risk,

  You've never made a commit to bhyve but somehow feel qualified to make 
risk assessments.

>>    And why the rush ? I'm yet to understand what the urgency for this
>> work is ? Who is demanding it ?
> 
> The users have been wanting this for well over a year, it was
> a frequently requested item when I wrote it.  It is long overdue.

  Right, so 3 weeks for MFC is perfectly acceptable in that case.

> You seem to be raising a bar higher than any other part of
> FreeBSD for this rather simple user command enhancement,
> can I ask what your objection is?

  The fact that you seem to think testing this is someone else's 
problem, in a subsystem where rigorous testing is a requirement.

later,

Peter.