Ping? I would like to get this done sooner rather than later so the SeaBIOS port is functional again. Without this change the generated SeaBIOS firmware image is non-functional.

I've tested with this fix and I'm able to build all the USE_BINUTILS ports, except for GCC which I haven't tried because my box runs out of memory when building it.

Do not take over the STRIP makefile variable, which is already used in bsd.port.mk to signal whether the install program should strip the binaries. Instead define STRIP_CMD and use STRIP just for the environment variables.

In D55509#1273416, @mat wrote:

Well, like everything committer related, it's in the committer's guide https://docs.freebsd.org/en/articles/committers-guide/#ports-exp-run, but I don't see what would break with this change.

There are not too many ports with USE_BINUTILS though, you could test build them :-)

Does it need an exp-run? Because I have no idea how to do that.

Can I please get an Ack/Nack from portmgr? This is required for SeaBIOS to be functional again when built on FreeBSD >= 15.

Add missing DIST_SUBDIR for xen-kernel

Adjust usage of ACPI_REDUCED_HARDWARE and remove elvis operator.

Picked the last couple of people that modified that file, and you happened to be there :). Thanks, will wait a bit for someone from ports to voice an opinion.

I think I'm missing the previous changes that introduce the support for KVM, as those haven't landed in the git repository yet. FWIW, while the CPUID has been reserved on Xen, the implementation is not done, so there's no way to test it on Xen.

I'm also fine if you just want to import the new headers from Xen 4.21. I haven't imported new ones recently because I didn't have a need for them, but our headers are now pristine imports from the xen.git ones, we don't carry any FreeBSD specific changes in there.

Tested with an amd64 VM live migration and still can see the ARP on resume.

Thanks, LGTM. Some months require the use of an apostrophe, so it needs to be factored into the months names.

Thanks for the review, will get the extra newlines removed and this committed.

Fix comments by markj.

Colin, could you please add Elliot Reviewed by tag when committing, if this turns out to fix the issues you saw on AWS? Thanks.

Thanks, will adjust tomorrow and commit.

Thanks for taking a look. I will push this together with the generic part.

Superseded by D46122 & D46123.

Some questions. I mostly miss where g_io_new_uz() and the new set of helpers are introduced, as I'm not finding them in main git branch yet?

Thanks, I've incorporated the feedback.

Incorporate feedback.

Move part of the logic to be common between all possible arches, just leaving the initialization of the resource manager arch-specific.

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?