We only need to maintain "backwards" compatibility in the stable/ branches (12 and 11) as far as I am concerned head can just nuke the compatibilty link, and have a 13.0 release notes item that is "fuse has been renamed to fusefs".

A question to @jhb, should the order of the enum and the code updated to be in alphabetic order, in a seperate review, it would only obfuscate the change to do it here.

Looks good, other than a lot of extra blank lines.

In D19587#427247, @kevans wrote:

Would iflib like any kind of UPDATING or relnote mention for the generated 'stable' MAC address likely changing (since we're restricting the range now to a subset of the FF OUI), or is it fine without explicit mention?

You can mark all my comments as done, you have addressed them to my satisfaction.

In D18670#425449, @crees wrote:

In D18670#425443, @rgrimes wrote:

I have performed a visual only review.

Greatly appreciated. Can I take that as approval by a src developer?

I have performed a visual only review.

Thank you, that is 100x clearer as to what is in the constant

Confirmation of a working Windows 2019 boot after this patch: https://lists.freebsd.org/pipermail/freebsd-virtualization/2019-April/007333.html

Can we get a review to cause bhyve -b to emit a deprecation warning notice (gone_in(13)) if someone tries to use it? That could be merged to stable/12, then the code in head killed.
This would also apply to the bvmconsole driver, is there someway to emit a warning during config(8) when someone uses a feature being deprecated? Doing this provides us feedback
sooner rather than later that some feature was in use some place.

Looks like someone may of removed a condition at some time in the past and not re-dented the code to produce a minimal diff.

Does this variable get used by default? I saw this here and just ignored it as I thought it would only be invoked if I asked for a DEBUG build from a level above. If we are always adding DEBUG_FLAGS to our compiles perhaps it should be called something else?

Please have a discussion on arch@ or filesystems@, this review needs more discussion

Can I get some final accept on this, I updated the open issues

I like it, just nits, that for the most part you can ignore, other than $FreeBSD: vs $FreeBSD$

This appears to be used to deal with a core hang on specific CPU's, we need to see that we have mitigated that in the host, and the decide what the appropriate action here is, I am uncomfortable with just making this silently disappear. Deferning to jhb.

Though this does fix your issue by silencing the log, it does little to improve the situation. I think what we may want to do is to add yet another option to the bhyve command that along with -w to ignore invalid MSR access to do so silently so that we do not have to add code like this everything a new msr comes into play. John, Patrick your thoughts on this approach?

In D19426#417642, @emaste wrote:

I would be comfortable with simply "https://bugs.freebsd.org/12344" as that can likely work forever.

Note that https://bugs.freebsd.org/12344 does work - we should accept either https://bugs.freebsd.org/bugzilla/show_bug.cgi?id= or https://bugs.freebsd.org/[0-9]+

I believe what your wanting is web server re-write rules, that would rewrite the URL in and out of the web pages to have the preffered form. Beyond my area of expertise to implement, but I know it can be done and that is probably the easiest place to do it (ie, no modifying bugzilla should be required.)

I removed a redundant "to" in the description. Patch looks good to me. Copyright over to jhb@

I'll review if you ack your are done updating John

Close, very very close, but still slightly short of leaving no doubt as to what goes here.

Missing is the change to the commit message template to update it to say URL instead of PRxxxx

Convert nat64_check_ip4 in sys/netpfil/ipfw/nat64/nat64_translate.h to use IN_foo macros rather than hand rolled code.

In D19380#414840, @manu wrote:

I don't think this is a good approach.
My goal for this is :

• Finish u-boot-install (https://gist.github.com/evadot/1bcad7c4c1e5cc7f9a692f4d19ab5421) to handle multi file u-boot
• Do a rpi-fw-install script and include it in the rpi-firmware package
• Create to GENERICSD image for arm64 (like the armv7 one), one with MBR and one with GPT scheme.
• Remove board configs that have no quirks from release.
• re@ could then create only two images (GENERICSD-MBR, GENERICSD-GPT) and install u-boot on each one based on list somewhere.

In D19316#414645, @karels wrote:

I agree with John that we should do everything we can to eliminate class A/B/C rather than just shuffle it around. ..trimmed...

Some of the patches I have already posted do infact remove the direct use of IN_CLASSA by use of the proper macro IN_LOOPBACK. I shall keep an eye out as I look over the code for issues that effect my stated goals in cleaning up things such that IN_ZERONET, IN_LOOPBACK, and IN_EXPERIMENTAL can be used to fully effect all places that are trying to deal with these ranges should they ever be redefined.

The added kernel code seems to be mssing INET/INET6 ifdefs. None of the inline comments are marked done, but the code looks as if you have addressed them.

In D19316#413794, @karels wrote:

Re: Classs A/B/C: I'd be quite happy to see those definitions go away.

In my first pass audit of a search results on IN_CLASS[A-E] the common use cases here are the default calculation of netmasks, 2 minutes ago I would of told you that probably can not go away, but it just hit me, IN_DEFAULTMASKFOR(i) could be written that would incorporate the ancient class rules in a central place and cleaning up some code. Thoughts?

In D19316#413638, @karels wrote:

I don't understand the purpose of this review. As it says, these changes should not be committed. I'm not actually sure of the official status of Class E, although I suspect it is still experimental/not for production use.

The changes well need expansion, the present form is to make a patch available so that the other patches can be tested.
A walk down through the RFC's say a few things, one is that it is not called Class E anymore. It is still reserved.

Add some more places that hand crafted macros are used, ip_input, ip_output, netdump code.

Address review comments from Patrick Mooney. Found some additional places that caching would be helpful so update them too.

In the future it helps to upload full file diffs, not sure what vcs your using or what its command is, for svn I use svn diff -x U999999.

In D19218#412862, @rmacklem wrote:

Whether or not "#ifdef INET6" and "#ifdef INET" should be in the code is still an open question.
I was hoping bz@ could answer this?
(I, personally, was of the understanding that this was no longer required/recommended for
FreeBSD sources. If bz@ does not know the correct answer for this, I will ask on freebsd-net@.)
At this point I have made no changes to the Makefile.
To build/run it, there is a small kernel change required, but I did not include that in this review.

Add handling of cores or threads > 254 by truncating to 0, per smbios 2.6 spec

In D18998#412749, @jhb wrote:

FYI, you can get SMBIOS specs here: https://www.dmtf.org/standards/smbios

In D18815#402284, @araujo wrote:

It doesn't looks quite right! I need more time to articulate better arguments, but this patch as it is, must not be committed in.

Wrap comment text, provide details of MADT_SIZE formula

Update to incorporate feedback from bde@ (mentor), wrap long lines, sort prototypes within group vm_get* in sys/amd64/include/vmm.h.

I smashed the wrong thing. I do not see the Makefile in the diffs, nor do I see the inline #ifdef's.

In D19218#412405, @bz wrote:

I think doing DNS things for these is not a good thing. Especially given inside an IP jail a "localhost" will give you different results.

Could you elaborate on that "give you different results?" This may be the very thing I am trying to say, and it may be what could break this code if run inside a jail, or in my other cases test bed with modified localhost value.

In D18816#411819, @jhb wrote:

In D18816#411818, @jhb wrote:

Pasting a reply from Rod:

I am just trying to fix the current bug that this code does not
work correctly if you raise VM_MAXCPU, it starts to give you
problems at something like 24 due to the stats array not having
space for the ipi table that tries to get added.

This also documents the size dependancy and removes the
false /* arbitrary */ comment.

The problem is you can't change it. Changing the constant in vmm_dev.h changes the ABI since the size of the structure is assumed in vmm_stat_copy()'s current API and that is also encoded in the ioctl value since the size of the structure is part of the constant. One of the approaches I described above is the only way you can do this without breaking the ABI.

pfg I think you miss understood, and upon looking I was not clear, it is not you that I am unhappy with about "playing with copyrights and licenses", it is NetBSD and possibly Charles Hannum who as Robert points out modified a license without ALL authors approval. I would be very upset if someone disturbed my disclaimer in this manner.

The review does nothing about addressing your other issues, it simply corrects a current state of affairs that is wrong if you raise VM_MAXCPU above 24.

Ping

Fabian, I have done some other work that moves forward with this concept, mostly correcting stuff that puts limits in place on how high VM_MAXCPU can go, and have WIP that actually changes this to a run time per vm value. Can we either abandon and retire this differential, and I'll start a new one or can I commandeer this one and make all the other work subordanate to it?