Mac os simple kvm gpu passthrough

New and Improved Mac OS Tutorial, Part 1 (The Basics)

• 

Due to certain recent developments, It’s become clear to us that it’s necessary to update and improve our OSX VM guide. A lot’s changed since we wrote it, and rolling in those changes will make the process much more user friendly and accessible to newer VFIO users.

So here’s part 1 of our attempt at making this process easier and more straightforward.

This site is ad-free and always will be. Consider supporting us on Patreon if you like our work and want to see more from us.

Prerequisites for a basic OSX VM

• A CPU supporting SSE 4.2 (most modern ones do)
• 64gb+ free space for VM image
• working basic knowledge of linux

Prerequisites For 3D Acceleration

• A Desktop with modern virtualization extensions and functional IOMMU
• Spare GPU to pass to the VM
• A linux install with a Qemu installation and configured to enable relevant platform features.
• If you want Mojave or future versions of OS X, you must have a 700 series nvidia GPU or an AMD gpu without the reset bug. (Generally 280X and older as long as they have a UEFI VBIOS)

Disclaimers and Warnings

• The vast majority of laptops won’t work, and using an eGPU to make them work is not covered in this guide.
• Using software acceleration and not doing passthrough will degrade performance to some degree
• No hackintosh project is update safe, and you will likely need to upgrade clover at points to maintain functionality.
• We do not condone software piracy. We don’t offer support for those who obtain commercial software through illegitimate methods.
• Pay attention to Apple ID related steps if you plan on logging in with a pre-existing account. Like any other hackintosh, you risk a temporary ban from apple if you don’t take proper measures.

Basic Setup

First, install a few prerequisite packages. You’re going to need qemu, python, pip, click, request, git, and all the relevant dependencies. So run:

then install click and request:

From here, you’re gonna need to use git to get the macOS-Simple-KVM repo from github:

Make sure to do this in a working directory where you want the VM files to live. The jumpstart script defaults to 10.15 Catalina. If you would rather install mojave, or high sierra, just run it with the corresponding argument, e.g. ./jumpstart —high-sierra, —mojave, or —catalina

The jumpstart script should make the recovery media for your VM to install from. After it finishes, simply create a qcow2 image by running

and adding these 2 lines to the end of the included basic.sh script

where MyDisk is the name of your image.

You may also want to change the mac address listed in line 23 ( -device e1000-82545em . ) of ./basic.sh at this point to avoid Apple ID issues, as the provided one is not unique. a new mac address can be generated easily by running openssl rand -hex 6 | sed ‘s/\(..\)/\1:/g; s/:$//’ and pasting the output into the mac= argument. You can also just generate a new mac address in the virt-manager GUI at a later stage (don’t log in in the meantime.)

From here you can boot your new VM by running ./basic.sh .

Basic Installation

Your vm should, after a short while, boot into clover, and then an OS X recovery partition. From here, click “Disk Utility” and format the image you created using the “Erase” button. Be sure not to format the recovery disk or the small partition labeled ESP.

After that, exit disk utility and click “reinstall OS X.” Follow the prompts and grab a coffee. This bit can take a while.

Hopefully by now, you have a basic working OS X VM.

OSX VM running on my modestly spec’d Laptop

From here, there are a few common tweaks you may want to do to improve performance and useability:

Change VM Resolution

Once you’re in the VM, you can change its resolution by editing config.plist in the clover ESP.

Start by copying ESP.qcow2 and renaming the copy something like ESP.qcow2.bak . Do the same for the firmware folder.

From there, boot into the VM, open a terminal and run sudo diskutil list . The 256MB disk is the one you want. Mount its first partition by running sudo diskutil mount diskXsY (where X and Y are the disk and partition numbers)

Open finder, navigate to “EFI” in the left bar under volumes, navigate to the clover folder, and open config.plist . There should be a section of this file that looks like this

Change this value to your desired resolution, e.g. 1920×1080. Note that some odd/intermediate resolutions like 1366×768 may not work well. Try to stick to more common 16:9, 16:10 and 4:3 form factors.

Increasing CPU/Memory

This process can increase overall performance if you have more than the default resources available to you. For memory, simply change the -m 2G \ line in basic.sh to a higher value. For CPUs, replace -smp 4,cores=2 \ with -smp cpus=X,cores=X,threads=1,sockets=1 \ where X is the number of threads you want to pass through. If you want to pass more than 8 threads, add to the number of sockets for every 8 cores as well. When and if you switch your configuration to virt-manager , DO NOT change the thread topology or model settings via the GUI. This can cause issues with clover and the boot process. If you do need more cores, just virsh edit and follow the same rules as above and do not change the cpu model type.

Switching to Virt-Manager

This will give you a GUI to launch and manage your VM with, making other adjustments and customizations easier. You’ll also need this for part 2 of the guide. Just install virt-manager and you can get started.

First things first: back up your ESP image and firmware folder as described in the resolution change section. Boot your VM, and press escape at the first UEFI dialog. Type exit, hit enter. This should bring you to the OVMF configuration menu. Navigate to Device Configuration > OVMF Platform Features, and set the resolution to the same value as your VM resolution. If you did not change your VM resolution, set it to 1280×720. Hit f10, Y, then press escape until you’re in the main dialog. hit continue and boot into the VM. Shut it down fully, then Boot again to make sure the change didn’t cause any issues.

Next, enable libvirt by running systemctl enable libvirtd.service virtlogd.service and systemctl start libvirtd.service and virtlogd.service . Open virt-manager and make sure you see Qemu/KVM in the connections window. Double click the connection and check the value for Virsh URI. If it’s qemu:///system then run every virsh command mentioned here with sudo.

Download the generic XML we provide here. Find and replace all instances of YOURPATH with the absolute path that corresponds to your VM’s firmware and image files. After you’ve edited the xml, run virsh define OSX.xml (use sudo if your URI is qemu:///system instead of qemu:///session ) in the same working directory you saved your XML to.

Restart Libvirt by running systemctl restart libvirtd.service virtlogd.service and open up virt-manager . You should have a VM named OSX under the Qemu Connection in the main window.

If you’ve already extensively customized your qemu script, you can run ./make.sh —add . This script is included in the repo. Edit the XML before defining, using uuidgen to create a new UUID to avoid issues with apple ID. The xml we provide will do so automatically.

If you get network startup errors, simply remove the NIC device in virt-manager and re-add it, manually specifying the device type to e1000-82545em . This should also generate a new MAC address. On Arch, you may get an error like:

To fix this, install ebtables and dnsmasq and try again.

Some distros (e.g. manjaro) come with badly configured or incompatible firewalls too. If you get an error saying NAT failed to connect or that the default virsh network is inactive, and running virsh net-start default doesn’t resolve the issue, you should try manually setting FirewallBackend= in /etc/firewalld/firewalld.conf to iptables

If you get Permissions errors related to your qcow images on boot, simply remove the affected qcow images and re-add them as sata devices. Virt-manager will ask if you want it to fix the permissions. Click yes.

If you get an error on startup similar to Error starting domain: path /dev/dri/bypath/pci-0000:00:02-0-render is not accessible. No such file or directory and you created your XML with ./make.sh —add , then it may have erroneously assigned a device to your qxl graphics. Simply edit your XML with virsh edit and remove the entire line containing that entry.

Troubleshooting

Qemu refuses to start after running basic.sh :

Check to make sure you have all dependencies installed. You have to manually install packages like virglrenderer and spice on some distributions. If your error includes unknown attribute type for SMBIOS , then your version of Qemu isn’t recent enough to support this project. You can try updating it by compiling a more recent version yourself or installing it through a 3rd party repo. The oldest version to support this feature is 2.8.

The Installer doesn’t have any listed hard drives:

Make sure you generated your qcow image, added it to basic.sh and formatted it to hfs+ in Disk Utility before starting the installer.

Installer fails with “Failed to Contact Validation Server”

Check your internet connection and firewall settings and try again. If it still doesn’t work, make sure your system time is correct.

UI is tiny:

You can change your VM resolution to a better supported one in the ESP, like 1920×1080, or use a tool like Enable-HiDPI-OSX to regain scaling functionality.

Part 2 of this guide covers GPU and Device Passthrough, CPU and IO optimizations, as well as other ways to improve your virtualized OSX experience. Special thanks to Foxlet for providing most of the groundwork for this new guide.

Consider Supporting us on Patreon if you like our work, and if you need help or have questions about any of our articles, you can find us on our Discord. We provide RSS feeds as well as regular updates on Twitter if you want to be the first to know about the next part in this series or other projects we’re working on.

Источник

KVM, PCI passthrough, Looking Glass и все-все-все

Искать выход долго не пришлось, но идея бить в бубен прожектором оказалась весьма странной. На тему проброса видеокарт в виртуальную машину интернет изобилует инструкциями различных времён и под различное железо. Чего стоит огромная статья на сайте Arch Linux’а [ 0 ]. Приведу сокращенную версию инструкции по пробросу видеокарты.

0. Проверяем, что железо поддерживает IOMMU

1. Включаем поддержку IOMMU в ядре.

GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash amd_iommu=on»
или
GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash intel_iommu=on»

Не забываем sudo update-grub .

2. Отбираем видеокарту у драйвера

Ищем нужные устройства и смотрим какие драйвера их используют.

04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau
04:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1)
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

Добавляем модули VFIO, чтобы они подгружались при загрузке.

Настраиваем модуль VFIO, чтобы он перехватывал устройства, не давая загрузиться основным драйверам. При необходимости добавляем в черный список, основной драйвер.

options vfio-pci ids=10de:0a65,10de:0be3
blacklist nouveau

3. Перезагружаемся и проверяем, что всё получилось

DMAR: Intel® Virtualization Technology for Directed I/O
или
AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Interrupt remapping enabled
AMD-Vi: Lazy IO/TLB flushing enabled

Составные устройства попали в одну группу.

/sys/kernel/iommu_groups/15/devices/0000:01:00.0
/sys/kernel/iommu_groups/15/devices/0000:01:00.1
/sys/kernel/iommu_groups/16/devices/0000:02:00.0
/sys/kernel/iommu_groups/17/devices/0000:03:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.1

Драйвера KVM и VFIO загружены.

Видеокарта для гостевой ОС захвачена VFIO.

04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)
Kernel driver in use: vfio-pci
Kernel modules: nvidiafb, nouveau
04:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1)
Kernel driver in use: vfio-pci
Kernel modules: snd_hda_intel

4. Настраиваем QEMU и запускаем гостевую ОС

sudo apt install qemu-kvm qemu-utils seabios ovmf virt-viewer

qemu-img create -f raw -o preallocation=full guest.img 50G
или
fallocate -l 50G guest.img

Запускаем виртуальную машину без проброса видеокарты для установки гостевой ОС. Так как стоит прицел на Looking Glass, то для гостевой стоит выбирать Windows 10. Windows 8/8.1 по последнем данным тоже поддерживаются.

#!/bin/bash
remote-viewer spice://127.0.0.1:5900&
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’w10.iso’,if=ide,format=raw,index=2,media=cdrom,cache=none \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga qxl \
-spice port=5900,addr=127.0.0.1,disable-ticketing \
-monitor stdio \
-netdev user,id=n1,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»

5. Пробрасываем видеокарту в гостевую ОС

Для начала загрузимся с двумя видеокартами. Смотрим, что проброшенная карта появилась в системе, ставим на неё драйвера и убеждаемся, что они заработали.

#!/bin/bash
remote-viewer spice://127.0.0.1:5900&
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga qxl \
-spice port=5900,addr=127.0.0.1,disable-ticketing \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root \
-device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on \
-device vfio-pci,host=04:00.1,bus=root,addr=00.1 \
-monitor stdio \
-netdev user,id=n1,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»

После как проброшенная видеокарта заработала, и в диспетчере устройств пишет «Устройство работает нормально», запускаем виртуальную машину только с проброшенной видеокартой.

#!/bin/bash
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root \
-device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on \
-device vfio-pci,host=04:00.1,bus=root,addr=00.1 \
-monitor stdio \
-netdev user,id=n1,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»

Подключаем к ней монитор и любуемся изображением рабочего стола гостевой ОС.

То место, где заканчиваются простые решения

И тут начинается, самое интересное. У кого-то, всё хорошо, картинка пошла и дальше всё просто. Мой опыт два раза споткнулся на стадии отсутствия изображения. Первый раз был проброс встроенной видеокарты процессора Intel 6700T HD 530, видеовыходы были пустые и неудача была списана на то, что встройки плохо прокидываются. Второй раз же пробрасывалась внешняя Nvidia GF210, которая уже была специально куплена для экспериментов. Результат был ещё более интересен. В non EFI режиме видеокарта успешно пробрасывалась и даже показывала картинку, но выключение гостевой ОС давало осечку .

Последующий проброс мог просто повесить хост. Пара часов лёгкого гугления приводит к тому, что проблема зависания видеокарты довольно распространённая. К этому ведёт как некорректное завершение работы виртуальной машины, так и с некоторым шансом даже корректное выключение. Как выход рекомендуют пробрасывать в EFI режиме. Но VBIOS Nvidia GF210 не поддерживает EFI…

Шить или не шить, вот в чем вопрос

Не шить. QEMU поддерживает подмену VBIOS при пробросе видеокарты. Но VBIOS ещё придётся научить поддерживать EFI режим. Обычно это рекомендуют проверять перед тем как начать проброс видеокарты, например здесь [ 2 ]. Но дело приходится иметь с тем, что есть, и искать свежую видеокарту с поддержкой EFI не хотелось. Значит нужно патчить VBIOS. Все операции выполняемые с VBIOS, делаются на свой страх и риск. Мной использовалось комплект ПО и инструкция к нему от сюда [ 3 ]. После считывания VBIOS получаем файл gt210.rom , патчим и на выходе имеем gt210_uefi.rom . Вот его и нужно подсунуть видеокарте при загрузке виртуальной машины.

#!/bin/bash
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root \
-device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on,romfile=gt210_uefi.rom \
-device vfio-pci,host=04:00.1,bus=root,addr=00.1 \
-monitor stdio \
-netdev user,id=n1,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»

Запускаем виртуальную машину и смотрим.

Темнота

Выходы видеокарты сияли темнотой. В очередной раз мораль проходила испытание неудачей. Первое, что приходит в голову, гостевая ОС падает при старте. Логи, мне нужны её логи. Для этого запускаем vga_qxl.sh . Смотрим предыдущий запуск. А там всё хорошо, кроме того, что питание резко дёрнули. Получается, что оно работает, хотя и не работает. Первая идея была подключиться по RDP и посмотреть, что же там происходит, но всё же лучше для этого использовать VNC, например tightvnc [ 4 ]. Устанавливаем VNC, настраиваем на 5600 порт и прокидываем этот порт для доступа из хоста.

#!/bin/bash
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root \
-device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on,romfile=gt210_uefi.rom \
-device vfio-pci,host=04:00.1,bus=root,addr=00.1 \
-monitor stdio \
-netdev user,id=n1,hostfwd=tcp:127.0.0.1:5600-:5600,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»

Подключаемся и видим рабочую машину, только монитор у неё странный Generic Non-PnP Monitor (Универсальный монитор не PnP). Картинка есть, значит можно пробовать запускать Looking Glass.

Looking Glass

Хоть данная технология и использует OpenGL, после gl пробел не нужен. А вот почитать инструкцию [ 5 ] на сайте проекта нужно обязательно. Для гостевой ОС скачать приложение захвата экрана looking-glass-host.exe [ 6 ], скачать и установить Microsoft Visual C++ 2015 Redistributable [ 7 ], скачать драйвер для IVSHMEM устройства [ 8 ]. Для хоста ставим зависимости, скачиваем и собираем клиентское приложение.

#!/bin/bash
sudo apt-get install cmake libsdl2-dev libsdl2-ttf-dev nettle-dev libspice-protocol-dev libfontconfig1-dev libx11-dev fonts-freefont-ttf libconfig-dev
wget github.com/gnif/LookingGlass/archive/a12.tar.gz
tar -xf a12.tar.gz
cd LookingGlass-a12
mkdir client/build
cd client/build
cmake ../
make

Запускаем виртуальную машину с IVSHMEM устройством. Размер памяти в 32Mb выбран для разрешения 1920×1080.

#!/bin/bash
if [! -f /dev/shm/looking-glass ]; then
touch /dev/shm/looking-glass
chown `whoami`:kvm /dev/shm/looking-glass
chmod 660 /dev/shm/looking-glass
fi
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root \
-device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on,romfile=gt210_uefi.rom \
-device vfio-pci,host=04:00.1,bus=root,addr=00.1 \
-device ivshmem-plain,memdev=ivshmem,bus=pcie.0 \
-object memory-backend-file,id=ivshmem,share=on,mem-path=/dev/shm/looking-glass,size=32M \
-monitor stdio \
-netdev user,id=n1,hostfwd=tcp:127.0.0.1:5600-:5600,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»

Подключаемся через VNC, устанавливаем драйвер на IVSHMEM устройство, возможно на него будет поставлен стандартный драйвер, находится в «Системные устройства». Запускаем looking-glass-host.exe. На хосте запускаем ./LookingGlass-a12/client/build/looking-glass-client .

На этом у меня заработала система с NVidia GF210, а затем по этому же маршруту удалось запустить Intel HD530. С разрешением экрана была маленькая проблемка, для смены на редкое разрешение, например 2048х1152, пришлось использовать Custom Resolution Utility [ 9 ].

Ещё один нюанс, при добавлении приложения looking-glass-host.exe в автозагрузку, нужно настроить автоматический вход пользователя, по соображениям безопасности гостевая ОС не даёт захватывать экран входа в систему.

Послесловие

Если не ставить задачу, получение изображения на физическом видео выходе, то данного результата будет достаточно для получения рабочей виртуальной машины с физической видеокартой и отзывчивым управлением. Управление осуществляется из хоста в отдельном окне или на полном экране. Однако есть нюансы.

Производительность. Накладные ресурсы на виртуализацию и не самая расторопная гостевая ОС не дадут с комфортом работать на слабом и средне-слабом железе. Потребуется мощный процессор не меньше 6-8 ядер, хорошая видеокарта для гостевой ОС, 16ГБ+ оперативной памяти, минимум по 8ГБ на каждую ОС. И танцы с бубном, чтобы выжать максимум из железа.
Терпение. Если сразу не заработает, то сил и времени придётся потратить прилично. Искать, читать, пробовать. Опять искать, читать и снова пробовать. Оставлю ещё несколько ссылок, которые мне попадались, возможно там будет ещё какая-нибудь полезная информация. [ 10 ] [ 11 ] [ 12 ]

Источник