Call for testing bhyve cpu topology additions

[Roman Bogorodskiy]

  Rodney W. Grimes wrote:

> There is a new version of the CPU topology review up at
> 	http://reviews.freebsd.org/D9930
> 
> I would like to ask that if people can test this and provide
> feedback that they do so.
> 
> It has some undesired side effects on vm-bhyve and probably
> other down stream tools, I am in the process of contacting
> the vm-bhyve author to see what can be done to clean up
> this output (if you are here please respond to this thread):
> 
> src-topo # vm list
> NAME            DATASTORE       LOADER      CPU    MEMORY    VNC                  AUTOSTART    STATE
> issd30g1        default         bhyveload   cpus=8,sockets=2,cores=4,threads=1 1024M     -                    No           Stopped
> 
> Notice that due to the new CPU string being much more complicated than
> the normal int it makes the output format ugly.  I have another change
> to vm-bhyve that I would like to see too, and that is to move the NAME
> to the end of the line and remove the 16 character limit.   I have done
> that in my local copy already.  This string and its parsing are designed
> to be Qemu compatible.
> 
> Here is a sample of my local vm-bhyve vm list output (no topology used):
> /tmp # vm list
> DATASTORE       LOADER      CPU    MEMORY    VNC                  AUTOSTART    STATE            NAME
> default         bhyveload   1      128M      -                    No           Stopped          fb-bld-10-amd64
> default         bhyveload   1      128M      -                    No           Stopped          fb-bld-11-amd64
> default         bhyveload   1      128M      -                    No           Stopped          fb-bld-11.0-p1-amd64
> default         bhyveload   1      128M      -                    No           Stopped          fb-bld-11.0-p1-i386
> default         bhyveload   4      512M      -                    No           Stopped          fb-bld-11_1-amd64
> default         bhyveload   4      512M      -                    No           Stopped          fb-bld-11_1-i386
> default         bhyveload   2      256M      -                    No           Running (30227)  fb-bld-head-amd64
> 
> Thoughts are to teach vm-bhyve to parse the string just as bhyve does
> and only output the vCPU count.  Other thoughts I have are to have
> it parse the string and output either vCPU if cores/threads is 1,
> or a simple S/C/T string.
> 
> If you are a downstream maintainer of one of the other vm management packages
> I am open to input.  The implemntation I have done should allow any existing
> tool that treated -c as a string to use the new topology without changes.
> This includes the in base vmrun.sh.

My general input on adding new features to bhyve is that it would be
nice to have a way to detect if the given bhyve version supports this
specific feature.

In this specific case it looks like this could be checked by running

  bhyve -c gibberish

and checking if the error message contains 'invalid cpu topology'
string.

But generally it would be good to have some more convenient way of doing
that because running bhyve to probe each feature is pretty expensive.

By the way, looking at the DR, it seems that the usage output (bhyve -h)
wasn't updated, but maybe I'm missing that without context.

> Also people using the sysctls:
> 	hw.vmm.topology.cores_per_package: 1
> 	hw.vmm.topology.threads_per_core: 1
> can continue to do so at this time, but there is work in process to
> deprecate these, that work includes making stable/11 emit a warning
> message if they are used, and remove them in head/12.
> 
> If I can get some significant test results back I plan to commit
> D9930 to ^head and merge it back to stable/11 3 days later.
> 
> Thanks,
> -- 
> Rod Grimes                                                 rgrimes at freebsd.org

Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20180310/0af762bb/attachment.sig>