Компания Oracle опубликовала корректирующий релиз системы виртуализации VirtualBox 7.2.2, в котором предложено 21 изменение:...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63866
хм... Странно... Даже интерфейс не поменяли.
> В дополнениях для хост-окружений с Linux на системах с ядром Linux 6.16 и новее для получения доступа к процессорным расширениям VT-x задействован API KVM.Неужели скоро dkms будет не нужен для VirualBox?
Так это просто же обычная проверка занято или нет
А то в новых ядрах автоматом загружаются kvm модулиПоэтому достаточно просто взять дефолтный линукс ака Ubuntu. Поставить на него Virtualbox.
И увидеть окно с падением - вот сиди и разбирайся почему.
Нет. Это дерьмо таки собралось ... В новости ошибка. Оно не работает через KVM из коробки (но существует вот-этот патч: https://github.com/cyberus-technology/virtualbox-kvm ). Там просто один коммит добавили, упоминающий KVM вскользь, на самом деле они просто его задействовали для получения одного уведомления от ОС.
в новости правильно написано> для получения доступа к процессорным расширениям VT-x задействован API KVM
то есть "если ты запущен, дай дорогу, освободи" - всё
Типа (100% накосячил, но идея такая)lsmod | grep kvm | wc -c && modprobe -r kvm_intel
Наконец-то я собрал это дерьмо с "KVM-патчем". Как оказалось, похоже что Oracle сама сделала большую часть работы для реализации поддержки KVM, а Cyberus доделала оставшееся, что орки намеренно не доделывали, чтобы народ не юзал неготовые фичи. Поэтому в самом патче и не упоминалась XSAVE, упомянутая в ReadMe - это требование не самого патча от Cyberus, а оригинального исходника от Oracle. В патче закодено#ifdef __KVM_HAVE_XSAVE
CAP_ENTRY_ML(KVM_CAP_XSAVE),
#else
CAP_ENTRY__U(55),
#endif
#ifdef __KVM_HAVE_XCRS
CAP_ENTRY_ML(KVM_CAP_XCRS),
#else
CAP_ENTRY__U(56),
#endifПричём XSAVE у меня проверку прошло не смотря на то, что в камне инструкции нет. Это - перечисление расширений KVM, подозреваю что в самом KVM при отсутствии XSAVE она эмулируется через FXSAVE + ещё несколько инструкций (как я и планировал). Более того, в исходнике перед использованием каких-либо расширений KVM их наличие проверяется в рантайме. То есть проверка на наличие расширений в начале при запуске вообще излишняя. `XCRS` кажется относится к реализации TEE (AMD SEV) и вообще нафиг не нужен, но его разумеется на старых камнях нет, и это к лучшему, мы их именно за это и любим - что в них нет встроенных DRM.
Поэтому блок #ifdef __KVM_HAVE_XCRS смело убираем. Блок #ifdef __KVM_HAVE_XSAVE можно оставить, так как присутствие этого расширения не зависит от присутствия инструкции в камне.
Этого оказалось недостаточно: вместе с timestamp counter это дерьмо unconditionally запрашивает MSR_K8_TSC_AUX - она же IA32_TSC_AUX - используется в RDTSCP, которой на старых камнях нет. В инструкци зачем-то стоит проверка на успешность выполнения, что все счётчики загрузились ... как-бы это лишнее. Но всё равно в целях оптимизации загнал под CPUID.
Всё равно не завелось ... оказалось орки не проверяя наличие MSRов (хотя в доке сказано проверять) их используют, и опять же зачем-то проверяют успех операции, если неуспешна - guru meditation. Написал программу, дампящую список доступных в KVM MSRов на машине, сравнил с используемыми, закомментил лишние ... и voila!
https://0x0.st/Kc8N.png/Screenshot_VBox_KVM_Core2Duo.png
Выводы малоутешительные: похоже что орки скоро выкинут VirtualBox совсем и поувольняют команду из двух человек, ил как минимум просто подропают архитектуры, ибо не осилили даже сделать 1 ioctl и проверку на наличие и нужность MSRов.
Свой патч доделаю и выложу позднее. Апстриминг его, как всегда, останется на вас.
Хоть в репозитории патча и было написано, что сеть в режиме NAT работает - на самом деле сеть не работает совсем, пока к машине подключён адаптер - она просто будет отказываться стартовать. Есть подозрение, что виртуальную сетевуху для VSOCK-сокетов можно добавить малой кровью...
Debian Sid - сломана полностью, виртуалки не грузятся, в dmesg - oopsы. Если включить lkrg - то драйвер становится невыгружаем. Если выгрузить насильно - можно словить kernel panic.
Не, какой прок - понятно. В отлимчие от QEMU эти хоть потрудились для Windows XP драйвера написать, да и GUI осилили. А QEMU не осилил реализовать виртуальные устройства, совместимые с этими драйверами.
Просто разные приоритеты, VirtualBox предназначен для новичков.
> Просто разные приоритеты, VirtualBox предназначен для новичков.Ты издеваешься? VirtualBox не предназначен для новичков. И называть "новичками" тех, кто не может себе позволить разрабатывать дрова под проприетарное ядро, где большинство дров разрабатываются не по документации, и даже не по исходнику, а через не очень легальный реверсинг винды в IDA Pro ... как-то не очень корректно. Просто оба проекта - говно, а кому нужно не говно - тот берёт VMWare.
Кстати, в RHEL 10 и клонах что-то поломали, у меня в VMWare загрузка до установщика и всё - серый экран. Alma поставилась с LiveCD, но после загрузки экран GDM пустой, тупо серый фон. Хз в чем причина. Проверял на VMWare 15 и 17.
Может быть дело в вейланде?
А что там неработает? Act97 codec? Сколько себя помню все виртуальные тухлые устройства работают в XP
В QEMU что не работает? Общие папки, паравиртуальный драйвер с интеграцией мыши, паравиртуальный драйвер для видео, интеграция буфера обмена... Там есть своя реализация общих папок ... но драйвер для неё для XP не портировали. Там есть поддержка аппаратного ускорения графики через VirGL или вообще vulkan (venus) - но драйвера для XP тоже нет. В общем QEMU на бумаге работает ... но пользоваться таким невозможно.
То Debian sid сломан полностью.А в стейбл тупо нет, апстрим послал мейнтейнеров к чертям.
Можно взять из fasttrack и пересобрать .
Зачем этот говняк нужен если есть libvirt?
Затем хотя бы, что QEMU начало ржаветь.
1. нет дров для Windows XP
2. libvirt сделан в виде тонны идиотских демонов, запускаемых при старте системы, и жрущих память как не в себя. То есть это говно бесполезно висит в фоне всегда - и жрёт дофига памяти. Мне пришлось их списать в утиль даже на 8гиговой машине. А теперь я на двухгиговой ...
используй virtualbox appimage
не ставь в нестабильную ось плохо работающее
>Debian Sid - сломана полностьюБагрепорт есть? Сиду и пологается быть сломаным, по определению.
Так как они всё завязали на почту - багрепортов не будет. К тому же у меня есть опыт по багрепортам про udev, которые просто игнорили, хотя в Убунту всё отлично работало, а вот на дебиане - звездец настал.
Я тут уже некоторое время пытаюсь собрать это "чудо". Полнейший кошмар - мало того, что зависимости заинлайнены (причём такие, просто при компиляци каких система в своп уходит, а компилятся полчаса, да, я о dxvk), а часть из них пропатчена, мало того, что вместо нормальной сборочной системы используется калечное говно, мало того, что при сборке шлангом- так ещё и не собирается вовсе, потому что код некорректный, но GCC такое терпит ... так ещё и перестало собираться на коде, зависящем от slirp.
Это ты еще хромиум не собирал.
А, ещё забыл ... это чудо-сборочная система одни те же файлы по несколько раз компилрует, своя копия - для нескольких модулей. Кто-нибудь научите ... этих ... использовать CMake по назначению. Потому что я уже больше месяца сижу без работающих виртуалок.
Так это прикол cmake как раз — для скольких целей исходник прописан, столько раз он и скомпилится. Обходится только костылями, через создание статической библиотеки.
Так и должно быть. Только в CMake единицы трансляци в библиотеки выделяются легко и непринуждённо. А в дерьмовой сборочной системе - со всем геморрой жуткий.
> Я тут уже некоторое время пытаюсь собрать это "чудо".…И не осилил.
Но это нормально. Современные проекты на то и рассчитаны, чтобы на юзерской машине под разными предлогами не собираться.
Ну или юзеры на это не рассчитаны. Короткий яркий период configure/make в прошлом (а я помню даже без configure).
Чтобы вы понимали уровень шизы:1. ./out/linux.amd64/release/obj/UICommon/include/COMWrappers.cpp компилился несколько часов при непрерывном свопинге.
-rwxrwxrwx 1 user user 34M сен 12 06:19 ./out/linux.amd64/release/obj/UICommon/gen/include/COMWrappers.o
-rwxrwxrwx 1 user user 1,6M сен 12 02:08 ./out/linux.amd64/release/obj/UICommon/include/COMWrappers.cpp2.
diff --git a/src/libs/xpcom18a4/python/src/PyGInputStream.cpp b/src/libs/xpcom18a4/python/src/PyGInputStream.cpp
index b8971ab3e..2e17502e6 100644
--- a/src/libs/xpcom18a4/python/src/PyGInputStream.cpp
+++ b/src/libs/xpcom18a4/python/src/PyGInputStream.cpp
@@ -103,15 +103,15 @@ PyG_nsIInputStream::Read(char * buf, PRUint32 count, PRUint32 *_retval)
const char *methodName = "read";
nsresult nr = InvokeNativeViaPolicy(methodName, &ret, "i", count);
if (NS_SUCCEEDED(nr)) {
-#if 0 /* VBox: new buffer protocol (though I could use it for Py_LIMITED_API and ditch the warning, but cpython specific) */
+#if 1 /* VBox: new buffer protocol (though I could use it for Py_LIMITED_API and ditch the warning, but cpython specific) */
Py_buffer py_view;
if (PyObject_GetBuffer(ret, &py_view, PyBUF_SIMPLE) == 0) {
if (py_view.len <= count) {
count = py_view.len;
} else {
- PyXPCOM_LogWarning("nsIInputStream::read() was asked for %d bytes, but the string returned is %d bytes - truncating!\n", count, py_size);
+ PyXPCOM_LogWarning("nsIInputStream::read() was asked for %d bytes, but the string returned is %d bytes - truncating!\n", count, py_view.len);
}
- memcpy(buf, py_view.py_buf, count);
+ memcpy(buf, py_view.buf, count);
PyBuffer_Release(&py_view);
*_retval = count;
} else {3.
diff --git a/src/libs/xpcom18a4/python/Makefile.kmk b/src/libs/xpcom18a4/python/Makefile.kmk
index 7bdadd058..e77d13aba 100644
--- a/src/libs/xpcom18a4/python/Makefile.kmk
+++ b/src/libs/xpcom18a4/python/Makefile.kmk
@@ -747,14 +747,14 @@ ifndef VBOX_ONLY_SDK
ifneq ($(VBOX_PYTHON_LIMITED_API_VER),)
DLLS += VBoxPython3
VBoxPython3_EXTENDS = VBoxPythonBase
- VBoxPython3_DEFS = $(filter-out VBOX_PYXPCOM_VERSIONED,$(VBoxPythonBase_DEFS)) Py_LIMITED_API=0x03030000
+ VBoxPython3_DEFS = $(filter-out VBOX_PYXPCOM_VERSIONED,$(VBoxPythonBase_DEFS)) Py_LIMITED_API=0x030d0000
VBoxPython3_INCS = $(VBoxPythonBase_INCS) $(VBOX_PYTHON$(VBOX_PYTHON_LIMITED_API_VER)_INC)
VBoxPython3_LDFLAGS.darwin = -undefined dynamic_lookup
ifneq ($(KBUILD_TARGET),darwin)
DLLS += VBoxPython3m
VBoxPython3m_EXTENDS = VBoxPythonBase_m
- VBoxPython3m_DEFS = $(filter-out VBOX_PYXPCOM_VERSIONED,$(VBoxPythonBase_m_DEFS)) Py_LIMITED_API=0x03030000
+ VBoxPython3m_DEFS = $(filter-out VBOX_PYXPCOM_VERSIONED,$(VBoxPythonBase_m_DEFS)) Py_LIMITED_API=0x030d0000
VBoxPython3m_INCS = $(VBoxPythonBase_m_INCS) $(VBOX_PYTHON$(VBOX_PYTHON_LIMITED_API_VER)_INC)
endif
endifЭто дерьмо просто нельзя даже поставить собираться, его приходится сидеть и высиживать и фиксить баги сборки, возникающие в непредсказуемых местах.
Это далеко не всё. И они ещё смеют называть это говно релизом!
https://github.com/python/cpython/pull/21117/files#diff-4ad6...>They are deprecated since Python 3.0.
(И окончательно удалены в 3.13).
В проекте:
># define PyObject_CheckBuffer(pAllegedBuffer) PyObject_CheckReadBuffer(pAllegedBuffer)
Почему виртуалки созданные в ветке 7.1*.* не загружаются в ветке 7.2.*?Там что, запланированно завезли новый формат с дропом легаси или это какой-то глюк?
Если виртуалки на ARM, то в прошлой новости написано, что нужно их завершить и удалить снапшоты, т.к. старые сохранения и снапшоты больше не поддерживаются.
> Если виртуалки на ARM, то в прошлой новости написано, что нужно их
> завершить и удалить снапшоты, т.к. старые сохранения и снапшоты больше не
> поддерживаются.
> https://www.opennet.dev/opennews/art.shtml?num=63727Нет, виртуалки созданы в x86-64 системе с такими же системами внутри. Новый Virtualbox их просто не открывает.
Если они совместимость сломали, то это тупо, потому что в виртуалках могут быть настроенные сервисы и заводить новые виртуалки и настраивать там всё с нуля, ну такое себе затея.
УМВРМожет правда в статусе "suspend" (или как он называется)?
Он у VirtualBox исторически глючноват.
> Почему виртуалки созданные в ветке 7.1*.* не загружаются в ветке 7.2.*?И если бы такое, то на форуме Virtualbox знатный вой наблюдался.
Но такого нет. Занчит какой-то частный случай.
>> Почему виртуалки созданные в ветке 7.1*.* не загружаются в ветке 7.2.*?
> И если бы такое, то на форуме Virtualbox знатный вой наблюдался.
> Но такого нет. Занчит какой-то частный случай.Да, я тоже так думаю. Есть у меня одно подозрение. Пока сидел на deb-дистрах, всё с virtualbox у меня было нормально. Но два года как переехал на Fedora и как какое-то обновление, так что-то да отваливается, но в основном было по мелочи, типа после обновления guest additions, отваливалась shared folder, но это быстро всё чинилось в течении пяти минут. А тут какая-то шняга, которая даже не нагугливается.
Ничего не ломались. Я при обновлении с 1 на 2 даже виртуалки не выключал. Из сохраненного состояния загрузилась без проблем.
> Ничего не ломались. Я при обновлении с 1 на 2 даже виртуалки
> не выключал. Из сохраненного состояния загрузилась без проблем.Ясно. Значит видимо и правда возможно, что это чисто приколямба Федоры. Попробую в другой системе потыкать.
> Решена проблема с пробросом USB-устройств поверх USB/IP.А вот это нужно будет проверить. Если мой ISDS220B с этим заработает, то проблем с гальванической развязкой сразу станет намного меньше.
По-видимому VSOCK-сокеты не поддерживаются.
>решена проблема с установкой 64-разрядной сборки Windows XP SP2А зачем оно вообще надо, если на поддержку 3D ускорения в XP забили
Тоже не понимаю зачем эту ХП мучать. Померла так померла.
Есть старое оборудование к которому существуют драйвера только под XP.
И там совершенно необходимо 3D-ускорение.
Вот тут есть дрова с аппаратным ускорением для Windows 98 https://github.com/JHRobotics?tab=repositories (не смотря на soft в названии), реализующие протокол, используемый в VirtualBox SVGA. При большом желании их можно и на XP портировать...
На fedora 42 виртуалка с windows 10 при включенном виртуальном 3д ускорителе абсолютно неюзабельна - падает в рандомные моменты времени работая меньше нескольких минут, в логах проблемы с amdgpu драйвером, жду vmware.
Сижу до сих пор на 7.1.12, amdgpu отлично работает, в виртуалке десятка летает. Зачем обновляться на сломанную версию и страдать, ума не приложу.
Сижу на 6.1. Windows 10 и 11 работают нормально.
Уже можно переходить с 7.1 на 7.2 ?
Нет, жди до 7.2.10 хотя бы.
На какой последней версии работает ReactOS? Тут на сайте гдето ранее как то даже писали.P.S.
Какая жесть в комментариях.. и это продукт от аж корпорации. Вот что делает opensource с людьми! Даже в freeware такого не видел.
- На те пользоваитель то - что, мне без корысти :(
Хоть я подозреваю что, она всё же есть в виде сливаемых данных и зомбирвоания ПК, ведь удобней для трояна - тип ПО не придумать же.
