Created attachment 234880 [details] vmw_pvscsi: Expand vcpuHint to 16 bit to aliagn with host side change. vcpuHint has been expanded to 16 bit on host side to enable interruptions to be routed to more CPUs. Guest side should align with the change. This change has been tested with hosts with 8-bit and 16-bit vcpuHint, on both platforms host side can get correct value.
My similar accepted patch for Linux: https://lore.kernel.org/lkml/20220620124744.578658384@linuxfoundation.org/
I think we can give it another try when https://reviews.freebsd.org/D36838 is merged. And, is the hypervisor (VMware in this context) responsible to process the endianness ? > vcpuHint has been expanded to 16 bit on host side to enable interruptions to be routed to more CPUs. On big-endian system, this seems break the vcpuHint function if guest side is not aligned with the change.
(In reply to Zhenlei Huang from comment #2) This driver is for ESXi product which only supports x86/x64. They are little-endian. So there is no need to consider big-endian system.
(In reply to Wentao Wang from comment #3) > This driver is for ESXi product which only supports x86/x64. They are little-endian. > So there is no need to consider big-endian system. Then the patch looks good to me.
(In reply to Zhenlei Huang from comment #4) Thanks for the review.
I think this is a good change.
Wentao, I notice the Linux change was posted from a vmware account, while this is posted from a gmail account. FreeBSD sets the 'author' to the actual person who wrote the change. Do you have a preference over which email address I should use?
(In reply to Zhenlei Huang from comment #2) This change shouldn't wait for D36838, also MAXCPU can be set in the kernel config file for testing.
(In reply to Ed Maste from comment #8) > This change shouldn't wait for D36838, also MAXCPU can be set in the kernel config file for testing. Yes, they are independent in principle. > I think we can give it another try when https://reviews.freebsd.org/D36838 is merged. What I thought after D36838 being landed ( depends on https://reviews.freebsd.org/D37067), it is easier to verify this patch actually works ( on FreeBSD VMs with CPUs count over 256 ). Anyway, it is unlikely this patch does not work. So feel free for the commit order of D36838 and this one.
(In reply to Warner Losh from comment #7) Eagle eyes. Please use wwentao@vmware.com to consistent with the change if possible. Many thanks.
Fixed in 923704f7b8efefd988bedd88ab68540332efa3f8 Should be safe to MFC, since it is a nop for MAXCPU <= 256
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=923704f7b8efefd988bedd88ab68540332efa3f8 commit 923704f7b8efefd988bedd88ab68540332efa3f8 Author: Wentao Wang <wwentao@vmware.com> AuthorDate: 2022-11-02 15:14:52 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2022-11-02 15:14:52 +0000 vmw_pvscsi: Expand vcpuHint to 16 bit to aliagn with host side change. vcpuHint has been expanded to 16 bit on host side to enable interruptions to be routed to more CPUs. Guest side should align with the change. This change has been tested with hosts with 8-bit and 16-bit vcpuHint, on both platforms host side can get correct value. This driver is for ESXi product which only supports x86/x64. They are little-endian. So there is no need to consider big-endian system. PR: 264840 Reviewed by: imp@, Zhenlei Huang sys/dev/vmware/pvscsi/pvscsi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
... but likely shouldn't unless there's other changes to merge (I hit save changes too quickly)
Just wanted to point out that there is also VMware Fusion Tech Preview for M1 Macs and it defaults to using pvscsi (so it's not only x86/x64); it's still little endian, of course, and pvscsi backed disks seem to work fine with 20221103 aarch64 snapshot.