Date: Fri, 7 Nov 2025 10:34:41 -0500 (EST) From: "Sean C. Farley" <scf@FreeBSD.org> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-virtualization@freebsd.org Subject: Re: bhyve command-line option order Message-ID: <68ef3bf0-22f8-7e23-4ec8-4e405b5e6daf@FreeBSD.org> In-Reply-To: <aQDoCeWY4FWhmrln@nuc> References: <385a62cf-22ad-c1ed-13fe-1ac8c7ab1408@FreeBSD.org> <aQDoCeWY4FWhmrln@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
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 -- scf@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68ef3bf0-22f8-7e23-4ec8-4e405b5e6daf>