In D44262#1020013, @ehem_freebsd_m5p.com wrote:

This is acceptable to me, but I believe the desire is have an okay by @markj. I believe resigning should make this more visible to @markj, rather than accepting.

In D44262#1010118, @ehem_freebsd_m5p.com wrote:

Most of what is presently here is definitely wrong. xen_intr_handle_upcall() retrieving the trapframe from curthread->td_intr_frame is definitely right. Issue is xen_intr_handle_upcall() needs to behave as a proper driver_filter_t for the XenPCI support. ARM(64) and RISC-V also need this, likely PowerPC would need similar. I do see two ways forward though:

1. I mentioned this before handing the patch for af610cabf1f off that I was uncertain about the handling of curthread->td_intr_nesting_level. As already mentioned, perhaps xen_arch_intr_handle_upcall() should be leaving the value alone?
2. I'm wondering about the indirect call to xen_intr_handle_upcall() via the XenPCI implementation. During that call curthread->td_intr_nesting_level would start out as 1, but would then end up as 2 when xen_intr_handle_upcall() calls xen_arch_intr_execute_handlers() => intr_execute_handlers() => intr_event_execute_handlers(). Perhaps xen_intr_handle_upcall() should be decrementing curthread->td_intr_nesting_level before it calls handlers?

I've noticed the load average seeming a bit on the high side on my ARM64 test machine. I'm unsure whether that might be this bug versus simply being a debugging kernel. I can state I've tried the second and it appeared to work.

In D44451#1016401, @markj wrote:

The current code however cannot be committed, because Elftoolchain objcopy segfaults when dong the conversion from elf32-i386 -> elf64-x86-64.

Is anyone actively working on switching? Maybe the objcopy bug is easy to fix.

In D44251#1009698, @ehem_freebsd_m5p.com wrote:

This is oddly similar to what Julien Grall did in 2015. For aarch64 the suggested range for the shared information page is available to the platform device. Perhaps the architecture should pass the struct resource * to xenpv?

xen_intr_handle_upcall() only requires the trap_frame because intr_execute_handlers() requires it, if the plan is to remove it from intr_execute_handlers() let's remove it from xen_intr_handle_upcall() at the same time.

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.