Re: 5.18 vmwgfx seems to break booting VirtualBox VMs

[Zack Rusin <zackr@vmware.com>]

> On May 9, 2022, at 6:57 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> 
> Hi Zack,
> 
> On 4/11/22 16:24, Zack Rusin wrote:
>> On Mon, 2022-04-11 at 10:52 +0200, Hans de Goede wrote:
>>> Hi All,
>>> 
>>> Fedora has received a bug report here:
>>> 
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D2072556&amp;data=05%7C01%7Czackr%40vmware.com%7C89c5a1adfffd434f102c08da31aaabcc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637876906347789531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=L3rfwX0R0XXgEJbI88kY%2B7SrIqyJtuC7VLcN97NUSuk%3D&amp;reserved=0
>>> 
>>> That Fedora rawhide VMs no longer boot under the VirtualBox
>>> hypervisor
>>> after the VM has been updated to a 5.18-rc# kernel.
>>> 
>>> Switching the emulated GPU from vmwaregfx to VirtualBoxSVGA fixes
>>> this, so this seems to be a vmwgfx driver regression.
>>> 
>>> Note I've not investigated/reproduced this myself due to -ENOTIME.
>> 
>> Thanks for letting us know. Unfortunately we do not support vmwgfx on
>> VirtualBox. I'd be happy to review patches related to this, but it's
>> very unlikely we'd have to time to look at this ourselves.
> 
> I somewhat understand where you are coming from, but this is not
> how the kernels "no regressions" policy works. For the end user
> a regression is a regression and as maintainers we are supposed
> to make sure any regressions noticed are fixed before a new
> kernel hits end user's systems.

I think there’s a misunderstanding here - the vmwgfx driver never supported VirtualBox. VirtualBox implementation of the svga device lacks a bunch of features, vmwgfx has been put on denylists before due to bugs in VirtualBox implementation of it, we just didn’t feel like playing games like having the driver query the hypervisor “are you really from VMware?” and refuse to load.

In this case it’s their lack of mksStats interfaces that’s the issue.  We can’t stop development of vmwgfx because our competitor was trying to reuse our work and didn’t implement the features we have. vmwgfx patches are now months ahead on drm-misc-next which should give anyone working on that device in VirtualBox plenty of time to fix it. I’m happy to spend my spare time reviewing patches that would make it work but it’s just not reasonable to expect anyone to spend their time in the office working on a directly competing product.

> At a minimum it would have been good if you had tried to at least
> reproduce this bug by installing Fedora rawhide inside an actual
> vmware VM. I've just spend a couple of hours debugging this and
> the bug definitely impacts vmware VMs too; and thus very likely
> also reproduces there.

We’re always running Fedora, it should always just work on vmwgfx.

> I've a patch fixing this, which I will send out right after this
> email.

That looks like a back porting issue. drm-misc/drm-misc-next is continuously tested on Fedora with vmwgfx so any breaks should never last more than a day. I’ll back port some patches tomorrow when drm-misc-next-fixes opens (because it’s after rc6). I’m sorry you had to deal with this, just send me an email next time, I should always have a pretty good handle on any issues with Fedora with latest vmwgfx.

z