While VirtualBox 4.1.22 has not been assigned to qa yet,
I have been trying it out.

Host is Mageia 2 x86-64 running 3.3.8-desktop-2.mga2, with
the extension pack installed, and the matching guest additions
in all guests.

First guest was Mageia 2 x86-64, running the 3.3.8-server kernel,
During execution of urpmi, to install a package, the guest system
became unresponsive, with one of the virtualbox threads stuck in
a device wait.  The only way to kill the guest was to reboot the
host system.

After that, restarting the guest, and then running urpmi recreated
the problem.  In the guest, reformatting the virtual drive and
reinstalling the guest os, recreated the problem.  The only way
to clear the problem, was to delete/rcreate the .vdi file, and
then reinstall the guest os.

I'm using a dynamically sized vdi file.  The host file system where
the vdi file is stored is an ext4 filesystem, on a luks encrypted
partition.  The host drive is a ssd drive, with the following mount
options ext4 (rw,noatime,user_xattr,barrier=1,data=ordered,discard).
In the guest setting, the vdi is setup as a sata drive, with the
ssd option checked.

I've now run into the same problem on a Mageia 1 x86-64 guest.

dmesg shows ...
[  203.645807] EXT4-fs (dm-0): Unaligned AIO/DIO on inode 1708686 by VirtualBox; performance will be poor.
[  481.367093] INFO: task VirtualBox:17482 blocked for more than 120 seconds.
[  481.367100] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  481.367107] VirtualBox      D 0000000000000000     0 17482   8755 0x00000000
[  481.367117]  ffff88037e825d78 0000000000000082 0000000000000001 ffff880308b02840
[  481.367128]  ffff8803add5da40 ffff88037e825fd8 ffff88037e825fd8 ffff88037e825fd8
[  481.367137]  ffff8804294bda40 ffff8803add5da40 ffff88037e825d88 ffff8803abb9c570
[  481.367148] Call Trace:
[  481.367161]  [<ffffffff8144fe9f>] schedule+0x3f/0x60
[  481.367171]  [<ffffffff81194d59>] inode_dio_wait+0xb9/0xe0
[  481.367182]  [<ffffffff81071130>] ? autoremove_wake_function+0x40/0x40
[  481.367251]  [<ffffffffa012b128>] ext4_setattr+0x338/0x550 [ext4]
[  481.367260]  [<ffffffff81053756>] ? current_fs_time+0x16/0x60
[  481.367270]  [<ffffffff811785fa>] notify_change+0x1aa/0x340
[  481.367281]  [<ffffffff8115bd4e>] do_truncate+0x5e/0xa0
[  481.367291]  [<ffffffff8115c015>] sys_ftruncate+0xd5/0x120
[  481.367299]  [<ffffffff81458e79>] system_call_fastpath+0x16/0x1b

htop on the host shows ...
   85 root       20   0     0     0     0 R 112.  0.0 23:23.31 kworker/u:9
   82 root       20   0     0     0     0 S 84.0  0.0 17:40.15 kworker/u:8
17459 dave       20   0 3779M 2210M 2099M S 11.0 13.8  2:50.15 /usr/lib64/virtualbox/VirtualBox --com

I'm not sure if this is a VirtualBox bug, a host kernel bug,

I'll be searching through https://www.virtualbox.org/search?q=ext4&noquickjump=1&ticket=on later, after I reboot again, so
I can check the guest's logs, to see if there is anything useful
there.