In D52968#1213405, @markj wrote:

In D52968#1212719, @corvink wrote:

It doesn't look like it fully freezes. However, it gets extremely slow. The circle of the Windows boot loader spins very slowly. Don't know if it will ever reach the desktop.

What output do you see if you run procstat -kk <bhyve PID> while this is happening?

It doesn't look like it fully freezes. However, it gets extremely slow. The circle of the Windows boot loader spins very slowly. Don't know if it will ever reach the desktop.

In D52781#1208670, @jon_xyinn.org wrote:

I think there may still be a relationship, jbo, since I've been having a different experience than you. However for now I'll try out some other bisecting before coming back to this. I'm going to test out switching out the "nvme" emulation for my drive to "ahci-hd" and see if that has any stability effect. I know people have also experienced issues with the nvme emulation before.

• only unlock vcpu when necessary
• avoid uneccessary sleeps
• fix some style issues

Hi,
I'm able to reproduce the issue and was able to fix it: https://reviews.freebsd.org/D52781

I'm not sure but it might be possible to use an RB tree [1] to simplify creating a list, sorting it and searching for elements (RB_NFIND).

In D51892#1186266, @jhb wrote:

Hmmm, do we not support INTx interrupts for passthrough in general? I guess we don't. There's a chance some guest OS might try to use INTx instead of MSI which won't work. Do you have more context on what is requiring this? Is it a driver in a Windows guest, or some other OS?

Setting every single cpuid value seems to be a bunch of work for user. Especially, as user have to set every single bit correctly. What's the way forward for this? How will bhyve receive some default cpuid values?

This should be merged into the previous commit D51552 shouldn't it?

Could you please describe a use case in the commit message?

• rename len to size to match common naming in pci_passthru.c

• use uint64_t instead of vm_* types
• account for new handler interface (including baridx)

• use uint64_t instead of vm_* types

• use uint64_t types instead of vm_* types
• add baridx parameter to read/write handler
  • this parameter can be used in the future to e.g. add a generic PCI config mirror in BAR space which is quite common according to QEMU [1]

@markj @jhb Any additional comments?

• fix build

• fix style issue
• use correct offset for 64 bit BDSM read/writes

• fix style issues
• make use of trunc_page and round_page

• fix style issues
• make global variables const

Becomes obsolete by D50806 and D50807.

• rebase onto main

• rebase onto main

• rebase onto main

• rebase onto main

• make use of igd_ops

• rebase onto main

Any comments on this?

Any comments on this?

In D46562#1064622, @rosenfeld_grumpf.hope-2000.org wrote:

Do I need a more elaborate commit message here, too?

Also, and in general, where do testing notes go, assuming they are needed?

Where's the commit message?

It would be a very good idea to improve your commit message. It would be nice to explain the use case in more detail (if possible). Additionally, it would be great to mention limitations of this new feature e.g. that user have to make sure to protect the tcp socket from unprivileged access.

ping

ping

ping