Fixed minor indentation.

• small correction

• added extra line

• some more cleanup

• fixed smp tb shootdown function pointer
• fixed double declaration and cleanup
• fixed indentation

added changes for function pointer and contigmalloc

• Merge branch 'freebsd:main' into review_branch
  • added some changes
  • refactored with pointer
  • pointer for the function

• Merge branch 'freebsd:main' into review_branch
• added some changes
• refactored with pointer
• pointer for the function

Changed the structure to remove extra FAM attribute.

The patch adds a macro in kernel.mk NO_WNO_GNU_VARIABLE_SIZED_TYPE_NOT_AT_END, to add an exception for compilation of hyperv_mmu.c c in conf/files.x86 .
This is to address the compiler warning for multiple fam attributes in hv_tlb_flush_ex structure. We are working with Hyper-V team on changing the structure definition for the
hypercall HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX and corresponding protocol. Once we reach the agreement, it could be changed on both Linux and FreeBSD guest.

Updated vmbus_var.h to remove the unused variable.

Code looks fine to me, but has the new functions been tested on Azure ? As in local Hyper-V we mostly dont use pci passthrough.

In D39395#899654, @yuripv wrote:

In D39395#899221, @schakrabarti_microsoft.com wrote:

Has this change been tested?

Of course, I used it as I was working on it :)

I didn't add anyone to reviewers though just yet as I am still thinking about the options here:

1. have this in base for a (bit better) resolution with console and scfb
2. have this entirely in drm-kmod (that will be completely separate change) for things like wayland compositors to work
3. have this in base and provide interfaces for drm module to re-use

• Changed the function vmbus_get_dma_tag to create the tag inside.

• Changed the function vmbus_get_dma_tag to create the tag inside.

In D41728#951388, @andrew wrote:

Can you include more context https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface

Updating the diff with arc

I have tested in arm64 and x86 and looks good to me.

In D40227#916382, @schakrabarti_microsoft.com wrote:

If possible please get the change thoroughly tested in Azure x86 platform or Hyper-V x86.

Tested on Hyper-V on ARM64 and it is working. The panic from gic redistributor is not coming.

If possible please get the change thoroughly tested in Azure x86 platform or Hyper-V x86.

I will try to test the patch on Azure x86 gen1 and gen2 and arm64.
I guess by this weekend I can complete it.

hyperv_dmamem_free() is removed, but hyperv_dmamem_alloc() stays, so what about the memory allocated by hyperv_dmamem_alloc()? How they will be freed?
Also it is not very consistent.
We need to do a thorough testing on Azure amd64 gen1 gen2 and arm64 with this patch.
Have you tested the change on Hyper-V x86 and arm64?

In D40227#915806, @andrew wrote:

hyperv_dmamem_alloc is used in amd64 code. I wasn't planning on touching that as I am unable to easily test the change.

Also if hyperv_dmamem_alloc() and hyperv_dmamem_free() is not in use, please remove them from vmbus. As they are dead code.

Has this change been tested?

@tsoome Can you please share the patch, would like to test it on Hyper-V arm64 and x86. Thanks.

In D37763#862942, @imp wrote:

Are there times other than when running as a hyperv guest that these might be needed?

In D36052#857738, @tsoome wrote:

small nits still, but good otherwise, I assume, this code does work as expected now?

In D36052#857698, @tsoome wrote:

In D36052#857682, @schakrabarti_microsoft.com wrote:

Setting other values than default values cause hang during comc_setup. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266248

It seems, you got some extra files included?

Setting other values than default values cause hang during comc_setup. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266248

Will put the

In D36467#834142, @emaste wrote:

It seems that some of the content of these comes from sys/dev/hyperv/vmbus/vmbus.c and other files under vmbus/. Are there corresponding changes to those?