On Tue, 28 Oct 2025, Mark Johnston wrote:
On Thu, Oct 23, 2025 at 10:00:42PM -0400, Sean C. Farley wrote:
I wrote a change to vm-bhyve[1] to be able to pass the options to
bhyve in the correct order to use GPU passthru. In the incorrect
order, bhyve will return an error. The question was raised: Is it
expected that bhyve will return an error depending upon the order of
command-line arguments, or should it be handling this scenario?
The issue is when "-s 31, lpc" is presented to bhyve. If it is
passed prior to "-o pci.0.31.0.pcireg.vendor=host", then there is no
error. However, if it is in the opposite order, this is returned:
$ bhyve ... -o pci.0.31.0.pcireg.vendor=host -s 31,lpc ...
pci slot 0:31:0 already occupied!
I will be updating my PR to make things a bit easier regardless of
the answer, but it would be nice to know if this is intended or not.
I don't really think it's intended, it's just an artifact of the way
option handling is implemented. The -s option creates a PCI device
and raises an error if one already exists in the configuration tree.
The -o option adds arbitrary configuration nodes and silently
overwrites existing nodes.
One solution which allows both orders would be to process -o options
after everything else. It's hard to say whether that might break some
existing command-line invocations though.
One other option would be to make -s more permissive, but that would
make it easier to flub command-line invocations.
That is what I suspected from glancing at the bhyve code. I will just
align my PR to work with the current bhyve behavior, which will not
cause any problems whether the behavior changes later or not.
Thank you.
Sean
1. https://github.com/freebsd/vm-bhyve/pull/56
--
[email protected]
