mkubecek's Posts

The only explanation of these warnings and errors I could come with would be that you are building on 32-bit architecture (or against a 32-bit kernel). As VMware does not support 32-bit CPUs (or host kernels) for quite some time, that is not really supposed to work.

@ivix wrote: ...are we seriously discussing installation of a fix from unknown person, from unverified source, which will be loaded as a kernel module? Good to see there are still people with some common sense. As for the "unverified source" part, would signing commits in the repository help? How can we get a fix from VMWare? Well, if I knew an answer to that, there would be no need for maintaining the repository in the first place...

@kamiller42 wrote: The 16.2.5 release says it's "unpatched workstation 16.2.5 module sources" and fails with same header files missing error when I run 'make'. You need branch "workstation-16.2.5", not tag "w16.2.5". Trying the 16.2.4 patched files release makes & installs without error, but VMware Workstation still fails. Some details about "still fails" might be helpful.  Then a vmware rebuild command, which results in a log like in the original post. Why would you do that? You already built and installed the modules, running vmware-modconfig would only attempt to rebuild them from the original tarball stored under /usr/lib/vmware which fails, unsurprisingly. All you need is "/etc/init.d/vmware restart". There are two ways: either you build and install the modules separately or replace the source original tarballs and use vmware-modconfig to build and install. Each of them has its pros and cons. It's all explained in the INSTALL file.

Branch workstation-17.0.1 has been created and pushed now. But using workstation-17.0.0 with 17.0.1 would work just as well, there are only two differences between 17.0.0 and 17.0.1 from VMware. One affects a windows only code path, the other is a workaround for the "spanning write" issue; it's different from mine but either is OK.

Hm... if gcc 4.8 does not handle the new version but has no problem with the old one, a workaround might be a switch between the two based on gcc version, i.e. something like   #if defined __GNUC__ && (__GNUC__ < 4 || __GNUC__ == 4 && __GNUC_MINOR__ < 9) ... old version ... #else ... new version ... #endif   Or simply define it as empty for old gcc like in the !USE_UBSAN branch.

No, using userspace includes, whether glibc ones or gcc ones, is exactly what's wrong. Kernel code should not include userspace header files. The correct solution is to replace all "#include <stdarg.h>" with "#include <linux/stdarg.h>" and the same for stddef.h.

@Mikerowrites: We do have a fix internally for this issue, and we'll be shipping it next week via Workstation 16.2.4. Sorry for being blunt but I'm afraid you - meaning rather VMware in general than just you in person - are still missing the point here. The core problem is not version X of Workstation not working correctly with version Y of Ubuntu (or Fedora or openSUSE or whatever). It's the very fact that you still think in the terms of "supported host/guest systems", i.e. you have a fixed list of versions of a very short list of distributions and completely disregard the rest. The Linux world does not work like this. There are not 3 or 4 distributions, there are hundreds. And, worse, more and more people move to rolling style distributions where you don't have discrete sequence of versions, unless you consider every daily snapshot a "version". Corporate people often say that they cannot test all of those but that's exactly where they are missing the point. For instance, when the init script does not get started because some distributions stopped shipping chkconfig by default (and some even not at all) in order to force people to migrate to native systemd units, it's not a problem "with Tumbleweed" (or Fedora), it's a generic problem with a generic solution. The same can be said for necessary updates of the kernel modules: if an upstream change in 5.18 kernel breaks the module, it's not a problem of a specific Fedora or Tumbleweed snapshot, it's a generic problem that is inevitably going to affect more and more systems as they move to 5.18 kernel. And it should be addressed as soon as 5.18 is released (the fix can be usually prepared as soon as rc1 is out). Sure, there are also specific issues with specific versions of specific distributions but those are rare, vast majority of the problems is generic and should be treated as such. An example: Workstation/Player 16.2.4 has been just released and it fixes (on kernel module front) one specific issue with the hack in the definition ASSERT_ON_COMPILE_SELECTOR_SIZE() macro which is going to "fix the problem on Ubuntu 22.04". More precisely, it fixes the problem on any distribution building its kernel with -fsanitize=shift. It does not, however, address any of the issues with build against 5.19 kernel (going to be released at the end of this week). Sadly, it does not address even known problems with 5.18 kernel (dropped HAVE_GET_KERNEL_NOFAULT and netif_rx_ni()) or 5.17 (net_device::dev_addr now const and accessors should be used), and AFAICS not even the include issues known since 5.15 and 5.16 (need to use kernel versions of stdarg.h and stddef.h rather than userspace ones). This is a result of thinking in the terms of fixed list of "supported releases": as long as it does not break completely (warnings are ignored, mostly) on one of them, you don't care. BtW, a fix for the "Ubuntu 22.04 issue" (exactly the same as yours, except for a comment and whitespace formatting) was known in public since January 2nd, i.e. more than half a year before 16.2.4 was released and more than 2 months before 16.2.3 was released. To sum up: as long as you don't change your understanding of the Linux world, this is going to be a recurring issue and people are inevitably going to be annoyed.

@continuum wrote: You may have noticed that the free VirtualBox usually installs flawlessly. VirtualBox is prone to the same kind of problems but it's usually (not always) faster to catch up. By the way - since Windows 10 the same applies to Windows hosts. At the moment using Win10 / 11 and latest Ubuntu may break your Workstation-setup with the next update. There is one big difference, though: with "Category B Linux", the source is public for both the kernel and the VMware host modules. So either you can adapt the modules to recent changes yourself or someone else can. With Windows, all you can do is to wait for VMware. My understanding of the core problem is that VMware does not actually understand linux worlds and their mindset is based on the old notion of "supported OS systems" (there is an actual list for both guest and host side). This list consists of some versions of best known (to them) linux distributions, mostly the enterprise flavor: RHEL, SLES, Ubuntu and few selected others. Even for these, recent releases and service packs are often missing. Rolling type distributions (Fedora, openSUSE Tumbleweed etc.) or less known distributions are our of their sight and thinking in terms of kernel versions rather than "supported host systems" is completely out of question. Well, perhaps not for developers (or at least not completely) but certainly for managers who make decisions about what will be released and when. And with Workstation (or even Player) itself being far from company focus, it would be naive to expect a significant change of the approach.

That's wrong, kernel code is not supposed to include userspace header files. The correct solution is to fix the include directives to include <linux/stdarg.h> and <linux/stddef.h> rather than <stdarg.h> and <stddef.h>

It's not my fault that VMware recently put multiple (formerly separated) sections into one. If you don't want to keep confusing people, it would be nice to always mention what product you are talking about... but that's up to you, of course.

@treee wrote: This the subforum for the Tech Preview which only runs on arm64 and does NOT support x86_64 in any way whatsoever. Not really... it does actually show in the "Workspace / Desktop Hypervisor" section which mostly deals with Workstation and Player. @treee wrote: Are  you sure you have got the right forum?  Are you?

and the cause of that is this addition to the linux kernel:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/include/asm/cpu.h?h=v5.17-rc7&id=9e45365f1469ef2b934f9d035975dbc9ad352116 That's highly unlikely as the commit you linked is arm64 specific so that I don't see how it could affect x86_64 kernel.

These are innocuous. Unfortunately, the VMware host module developers to not care much about warnings so I would be rather surprised if these were the only warnings you got. But to be fair, they finally addressed some of the long existing ones between 16.2.1 and 16.2.3.

Just include <linux/stdarg.h> and <linux/stddef.h> instead, like commits 9a6a17fe0bc6 and 4232f780eb11 do. Kernel code is not supposed to include userspace headers which is what existing include directives used to do.