Call for testing bhyve cpu topology additions

[Rodney W. Grimes]

> >>    And as mentioned in the review, I'd also like to see your Windows
> >> desktop guest test results with this change.
> > 
> > I do not run any windows in bhyve as bhyve can not run the
> > windows I use due to missing/broken ATA support.
> > The person I was helping with bhyve windows regression tests has
> > become unavaliable.
> 
>   I'm staggered by this. The *only reason* for having this change is to 
> get past the 1/2 socket limitation when running Windows desktop guests. 
> It has no impact on any other guests, whatsoever.

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).

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.

> 
>   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?

> 
> >>    Standard MFC time is 3 weeks.
> > 
> > Can you point to this some place?  My understanding is that
> > MFC is at the discretion of the committer, and the only
> > thing the big list of rules says:
> 
>   This is project culture, which you should have seen observing MFC 
> times for commits.

And I consider this change rather trivial and with near 0 risk,
so choose to use a 3 day MFC timer for it.  The worse that can
happen is the user would have to use the old sysctls which I
left in place with full compatibility.

>   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.

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?  If you think the topology
seen by the guest is going to be bad, that bug exists today
for anyone trying to use the sysctl's, perhaps we can find
that there are bugs if we get this in the hands of the user
rather than yet again delay a new feature for what appears
to be tests of code paths very minimally effected (change
of a variable name) by this patch.

Regards,
-- 
Rod Grimes                                                 rgrimes at freebsd.org