Check linear address and use %u to print an uint32_t

In D43928#1003296, @ehem_freebsd_m5p.com wrote:

Depending on where xen_intr_disable_source() and xen_intr_disable_intr() were being called from, this is fixing both 1797ff962769 and some other commit. Certainly 1797ff962769 may have exposed this, but the is_valid_evtchn() call was needed earlier (could be rG76acc41fb7c7, or even before).

Context adjustments due to modifications in previous patches

Fix comments.

Add Xen guest assert.

Add comment.

Upload diff with context.

In D43764#998154, @markj wrote:

In D43764#998147, @royger wrote:

In D43764#998144, @markj wrote:

Could you please upload diffs with context? i.e., add -U99999 or so to diff's parameters.

Hm, that's the output from git format-patch. I wonder why it doesn't pick the context automatically from the repo?

How are you uploading it? arc diff --create <revision> or git arc create will indeed fetch context automatically. If you're manually uploading diffs, then it won't. See https://wiki.freebsd.org/Phabricator#Create_a_Revision

Fix possaible use of init_fn uninitialized.

In D43764#998144, @markj wrote:

Could you please upload diffs with context? i.e., add -U99999 or so to diff's parameters.

Fix detection

In D43508#993354, @jhb wrote:

Oof, ok. I guess for now this approach is fine of treating "HV" as a secondary signature (i.e. one other hypervisors will emulate). I do think we do probably want to eventually transition to more of a "hypervisor_present()" sort of thing I described which can either be a bitmap or something else and remove direct checks of vm_guest. One instance of s/HperV/HyperV/ in the commit log btw. (I really wish code review tools permitted per-line comments on commit logs, not just the diff.)

In D43508#992957, @jhb wrote:

I think what we want instead is for vm_guest to be the "main" hypervisor for the first leaf, but have a way that drivers can ask "is hypervisor X present" when checking for X-specific extensions or PV devices, etc. That is, if you are running under Xen but with support for some Hyper-V PV devices, I think vm_guest should still be XEN, but we want the PV device drivers to be calling some bool hypervisor_present(enum) instead, so that instead of doing if (vm_guest == VM_GUEST_HV) the drivers call if (hypervisor_present(VM_GUEST_HV)).

Add line break after full stop.

While the hypercall headers where originally imported from Linux, I think there's very little chance we will even sync again with Linuxes version, so s/__must_check/__result_use_check/ in the Xen hypercall headers would be the best solution IMO. Playing games with ifdef/ifndef is usually not a good idea.

Change LGTM, thanks :).

In D42343#969529, @ehem_freebsd_m5p.com wrote:

In D42343#969231, @royger wrote:

My opinion is that halt should behave equally on bare metal than when virtualized, otherwise it's just going to confuse users. If we believe that halt should behave differently (iow: do power off) it should be changed uniformly.

First, my current opinion is FreeBSD on Xen as Domain 0, should behave similarly to FreeBSD on bare metal.

Second, my current opinion is spinning in a halt-loop is a poor fit for FreeBSD on Xen as a user Domain. The reason is the domain ends up sitting there doing nothing useful.

My opinion is that halt should behave equally on bare metal than when virtualized, otherwise it's just going to confuse users. If we believe that halt should behave differently (iow: do power off) it should be changed uniformly.

There's also SHUTDOWN_crash which should likely be used if the kernel panicked, likely by checking KERNEL_PANICKED()?

Are you fine with committing it yourself? Might be worth requesting for backport to the releng 14.0 branch, as it's a low risk fix IMO.

Would it be simpler to not set IFCAP_LRO in the if_setcapenable() call on create_netdev() if xn_enable_lro is false? I think that way we would avoid exposing feature-gso-tcpv4 on xenstore and you won't need to modify talk_to_backend().

I will look in more detail on Monday when I'm back from PTO, but overall I agree it should be fixed. I will also look into possible solutions to detect when forwarding is enabled and disable LRO automatically.