наигрался с настройкой проброса видеокарты в qemu через vfio-pci, а теперь возник закономерный вопрос — как сделать то же самое, но от простого пользователя? Из того, что удалось нагуглить, — предложение сменить права доступа для устройств в /dev/vfio/*. Сейчас оно выглядит так:

$ ls -l /dev/vfio
crw-rw-rw- 1 dmitriy qemu 246,   0 фев 16 00:57 1
crw-rw-rw- 1 dmitriy qemu  10, 196 фев 16 00:57 vfio

Да, видеокарта находится именно в 1-й группе. При попытке запустить ВМ получаю

qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0,bus=root.1,addr=00.0,multifunction=on: VFIO_MAP_DMA: -12
qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0,bus=root.1,addr=00.0,multifunction=on: vfio_dma_map(0x55ba05696ef0, 0x0, 0x80000000, 0x7f2bd3a00000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0,bus=root.1,addr=00.0,multifunction=on: VFIO_MAP_DMA: -12
qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0,bus=root.1,addr=00.0,multifunction=on: vfio_dma_map(0x55ba05696ef0, 0x100000000, 0x180400000, 0x7f2c53a00000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0,bus=root.1,addr=00.0,multifunction=on: vfio: memory listener initialization failed for container
qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0,bus=root.1,addr=00.0,multifunction=on: vfio: failed to setup container for group 1
qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0,bus=root.1,addr=00.0,multifunction=on: vfio: failed to get group 1
qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0,bus=root.1,addr=00.0,multifunction=on: Device initialization failed

Явно где-то не хватает прав доступа, но вот где именно...

забавный у них там юмор

 0:08.04 updating cache ./config.cache
 0:08.04 creating ./config.status
 0:08.13 Checking for beer in the fridge...
 0:09.84 Finished reading 674 moz.build files into 1427 descriptors in 0.93s

за пивом что ли сходить...

что-то его нынче как-то лихорадит. Господа, а вы какими серверами ключей пользуйтесь?

интересно вот, как уважаемые лоровцы генерируют всякие-разные Makefiles на питоне.

В общем случае задача такова — есть некоторая структура проекта, включающего в себя разные типы файлов. Есть хренова туча архитектур ПЛИС, на которых этот проект должен работать, и разумеется, каждый вендор лепит свои утилиты для синтеза и place & route. Делать скрипты для сборки всего из Makefile неудобно (это ж бесконечные echo «bla-bla-bla $(SOME_VAR)» >> build.tcl), а результат люто тормозит, например, в mingw (там, где каждый вызов шелла «дорогой»).

На питоне, в принципе, дергать шелл не нужно, но уж как-то больно уродливо смотрятся бесконечные либо %, либо format()'ы.

Подскажите феншуйный метод.

господа, не посоветуете ли опенсорсный компилятор для этой премерзкой архитектуры (CISC с тремя регистрами общего назначения! в 21-м веке)? Гугл говорит, что когда-то был порт gcc и newlib на нее. Интересно, стоит ли вообще связываться с ним?

По поводу sdcc тоже непонятно: вроде hc08 есть, а от hc12 он отличается совсем чуть-чуть...

Как-то так получилось, что имея железку с 256 килобайтами памяти, захотелось мне ее конфигурировать через веб-морду. Ну там светодиодами мигать, режимы работы uart переключать, да мало ли. Т.е. запустить на ней какой-никакой, но tcp-стек и натянуть на него еще какой-нить минимальный веб-сервер.

Сама железка — это девайс на основе fpga. Процессор, ethernet mac — реализованы в ней, соответственно. Беда только в том, что в такой объем памяти никакие не то, что линуксы, но и rtems толком не влезает.

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

Короче говоря, подскажите, есть ли активные (или достаточно зрелые) проекты, которые бы позволили такую задачу решить.

---

UPD: забыл написать, что оно портабельным должно быть. Т.е. по минимуму всякого хардкора с ассемблером. В идеале весь стек должен дергать фунции типа hal_send() и hal_receive() для отправки «сырых» данных драйверу.

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

Вот вопрос у меня такой: чего народ так хвалит дисковые тормоза? От песочка, который так или иначе с водой из-под колес летит на задний тормоз, колодки стачиваются в нуль за пару поездок. Не лучше ли вариант с передним дисковым (основной) и задним V-brake (вспомогательный)?

в приложениях из kf5, запущенных из-под i3wm, не отображаются иконки (например, в okular, dolphin...). При этом, если запустить сессию с плазмой — то все иконки на месте.

Вопрос к знатокам: через какой хитрый механизм в kf5 приложения pixmaps получают и как бы мне его вручную запустить?

--- UPD: помогло выставить переменную окружения XDG_CURRENT_DESKTOP=KDE

когда firefox начал открывать pdf-файлы gimp'ом, озадачился, почему так случается. Смотрю на то, что предлагает xdg-open:

$ XDG_UTILS_DEBUG_LEVEL=2 xdg-mime query default application/pdf    
Checking /home/dmitriy/.local/share//applications/mimeapps.list
Checking /usr/local/share/applications/defaults.list and /usr/local/share/applications/mimeinfo.cache
Checking /usr/local/share/applications/defaults.list and /usr/local/share/applications/mimeinfo.cache
Checking /usr/share/applications/defaults.list and /usr/share/applications/mimeinfo.cache
zzz-gimp.desktop

Наткнулся вот на стандарт, в котором пишут, что я могу в $XDG_CONFIG_HOME/mimeapps.list создать секцию наподобие

"[Removed Associations]
application/pdf=zzz-gimp.desktop

и все будет хорошо. Добавляю указанную секцию в файл ~/.local/share//applications/mimeapps.list — ничего не меняется. Лезу смотреть в то, что это за скрипт xdg-mime и с удивлением обнаруживаю, что там вообще нет нигде обработки секции «[Removed Associations]».

Собственно, вопрос — есть ли более-менее вменяемая замена xdg-utils, желательно более-менее следующая стандартам freedesktop?

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

В общем, нет ли какого-то более-менее устоявшегося способа чтения чужого кода для этой фигни? В то вот захотелось себе собрать spectrum2, а оно — на scons завязано...

читаю документацию по portage, там пишут, что есть два способа задания USE-флагов

1. Глобальный (make.conf)

2. Для отдельного атома (/etc/portage/package.use)

А можно ли portage задавать use-флаги в стиле «флаг» — «список пакетов»? Очень удобно было бы, например, для мультилиба (abi_x86_32)

помогите, пожалуйста, с черновиком стандарта IEEE P1735 (шифрование IP-ядер).

https://standards.ieee.org/findstds/standard/1735-2014.html

случилась тут неприятность — часть секторов на жестком диске перестали читаться. Прогнал badblocks, определил их номера, перезаписал с помощью dd. Вроде диск «ожил» (т.е. в SMART Current_Pending_Sector обнулился).

На всякий пожарный захотелось весь диск перечитать и переписать заново. И чего-то гугл молчит на тему. Т.е. что, задача настолько нестандартная, что проще самому написать скрипт, который блоками по, скажем, 10 мегабайт, читает диск и пишет их назад?

В общем, эти ребята, вместо того, чтобы выдать мне сорсы ядра, глибц и бизибокса, стали мутить обычную бюрократическую тягомотину. Ну и хрен с ними, воспользуюсь моментом, чтобы малость им подгадить, а заодно и попиариться.

В общем, когда-то давным-давно народ приноровился клонировать Application Modules для их осциллографов. По сути, это i2c-eeprom, в которых тупо записана строка, идентифицирующая купленный модуль. А сами модули — вроде неплохи, позволяют без лишних телодвижений анализировать, например, I2C, SPI, UART, CAN, LIN и прочие вкусности.

Расстраивало то, что для MSO2024, с которым я работаю, таким образом можно было разлочить только 2 AppModule'а. Ну, и торчащая из сокета самопальная железка — тоже фигня.

Короче, малость подшаманил с самим бинарником приложения осциллографа (обычное такое приложение под ppc32) + через LD_PRELOAD подгружаю эмулятор ключей. Кому надо — вот оно (гитхаб). Собственно, если найдутся желающие, можно где-нибудь выложить и готовые бинарники.

Пробую тут буквально пробить стену лбом, а именно — заставить тектрониксов прислать мне сорсы ядра и busybox, которые крутятся на моем осциллографе (MSO2024). Российское представительство, как я понимаю, это просто продавцы. Американцы разводят волокиту, тупо не отвечают.

В общем, не понимаю, в какое спортлото мне писать. Может, кто добивался от таких товарищей положенного?

Пробую пробросить видеокарту в гостевую ОС в такой вот аппаратной конфигурации:

1. Motherboard (есть в списке VT-d): Intel DZ77BH-55K, работает в режиме UEFI с прошивкой версии BHZ7710H.86A.0057.2012.0208.1904

2. Процессор (есть в списке VT-d): Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz

3. Видеокарта (есть в списке VT-d): NVIDIA Corporation GF100GL [Quadro 4000] [10de:06dd] (rev a3)

В качестве основной используется интегрированное в процессор видеоядро. ОС — gentoo с ядром 3.18.11 и конфигом от дебиана с небольшими изменениями (модули для поддержки AHCI собраны статически).

Системы виртуализации. Пробовал разное

1. Qemu (kvm) с режимом pci-assign.

qemu-system-x86_64 \
    -boot c \
    -M q35 \
    -m 2048 \
    -smp 4 \
    -usbdevice tablet \
    -enable-kvm \
    -usb \
    -device usb-ehci,id=ehci \
    -drive file=./debian.img,id=mydisk \
    -device virtio-net-pci,netdev=mynet0 -netdev user,id=mynet0 \
    -bios /usr/share/seabios/bios.bin \
    -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
    -device pci-assign,host=01:00.0 \
    -device pci-assign,host=01:00.1 \
    -vga none \
    -curses

Итог — зависание при старте. Если отключить устройство 01:00.0 (это видеокарта) — то стартует нормально.

2. То же самое, но с vfio-pci. Конфиг аналогичный, строка для видеокарты (и ее звуковухи)

-device vfio-pci,host=0000:01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=0000:01:00.1,bus=root.1,addr=00.1 \

Результат — висим на старте без каких бы то ни было сообщений.

3. Xen 4.5 с тулстеком xl.

name = "debian-domU"
builder = "hvm"
memory = 1024
vcpus = 2
disk = [ "tap:qcow2:/mnt/Storage/vm/debian/debian.img,xvda,w" ]
vif = [ 'mac=00:16:3e:ff:ab:cd,bridge=br0' ]
vnc = 1
vnclisten = '127.0.0.1'
vncdisplay = 10
boot = "cd"
#gfx_passthru=1
pci = [ "0000:01:00.0" "0000:01:00.1"]

с gfx_passthru=0 стартует нормально, с 1 — сыпет ошибки

libxl: error: libxl_dm.c:1499:device_model_spawn_outcome: domain 4 device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1322:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:1603:kill_device_model: Device Model already exited

вывод dmesg, связанный с IOMMU

[    0.000000] Intel-IOMMU: enabled
[    0.028942] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a
[    0.028949] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a
[    0.029032] IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.973877] IOMMU 0 0xfed90000: using Queued invalidation
[    0.973878] IOMMU 1 0xfed91000: using Queued invalidation
[    0.973880] IOMMU: Setting RMRR:
[    0.973890] IOMMU: Setting identity map for device 0000:00:02.0 [0xbb800000 - 0xbf9fffff]
[    0.974193] IOMMU: Setting identity map for device 0000:00:14.0 [0xba22e000 - 0xba249fff]
[    0.974212] IOMMU: Setting identity map for device 0000:00:1a.0 [0xba22e000 - 0xba249fff]
[    0.974228] IOMMU: Setting identity map for device 0000:00:1d.0 [0xba22e000 - 0xba249fff]
[    0.974237] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    0.974245] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
[    1.034974] AMD IOMMUv2 driver by Joerg Roedel <joerg.roedel@amd.com>
[    1.035504] AMD IOMMUv2 functionality not available on this system

В общем, какой-то no luck. Собственно, прошу помощи.

Пытаюсь зашифровать один блок (16 байт) данных с помощью aes-128-ecb (поблочное шифрование без сцепления шифротекста) — соответственно, ожидаю, что на выходе из 16 байт исходного текста получится 16 байт шифрованного. openssl почему-то добавляет туда еще шифрованный nonce.

Исходные данные:

$ xxd open.dat 
0000000: 0001 0203 0405 0607 0809 0a0b 0c0d 0e0f  ................

$ openssl enc -aes-128-ecb -e -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 -in open.dat -out out.dat

$ xxd out.dat 
0000000: 0fb5 d019 0539 afdf 30e9 5500 5859 6cc5  .....9..0.U.XYl.
0000010: 7d07 5d65 6b71 2b5f 91ff 62ec 20d9 5aac  }.]ekq+_..b. .Z.

out.dat почему-то содержит 32 байта вместо 16. Я ошибаюсь, или так действительно должно быть?

вот уж не знаю, наверное, опять с подразделом ошибаюсь, но все-таки...

По работе столкнулся с черновиком стандарта IEEE P1735. Вкратце — это «контейнер» для шифрования IP-ядер, написанных на VHDL/Verilog, сессионный ключ шифруется RSA, тело модуля шифруется с помощью AES. Утверждается, что такая схема позволяет вендорам распространять шифрованные IP-ядра конечным потребителям. Ну, например, ARM может так продавать свои ядра какому-нибудь Qualcomm.

Я вот чего не пойму — шифрование же предназначается для того, чтобы Алиса и Боб (которые доверяют друг другу) могли общаться через незащищенный канал. А тут получается какая-то гомосятина: входные данные шифруются вендором, отдаются заказчику, который из целевой софтины (например, из Design Compiler того же) выдирает приватный ключ — и вуаля, расшифровывает нафиг весь исходный код. ИМХО, в таком случае нужна обфускация, нет?

Да, по поводу стандарта: статья на aldec.com

Зачесалось тут прикрутить cmake для разработки прошивки 8051-совместимого контроллера. За неимением альтернатив компилятор — sdcc-3.4.0. В общем, по мануалу, найденному в гугле, создаю toolchain.cmake

# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Generic)

# which compiler to use for C (dummy for CXX)
SET(CMAKE_C_COMPILER sdcc)
SET(CMAKE_CXX_COMPILER true) 

# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /usr/share/sdcc)

SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRIRY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

# set proper linker flags
SET(CMAKE_EXE_LINKER_FLAGS "--out-fmt-ihx --code-loc 0x400 --code-size 0x8000 --xram-loc 0xf000 --xram-size 0x300 --iram-size 0x100" CACHE STRING "Linker flags" FORCE)

и файл с проектом CMakeLists.txt:

PROJECT("TEST" C)
ADD_EXECUTABLE(hello bsp.c main.c)

Сборка такого мелкого проекта вполне работает после

$ mkdir build && cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..

Но вот make clean не удаляет все файлы: остаются hello.lk, hello.map, hello.mem.

Подскажите, пожалуйста, куда копать, чтобы в спецификации тулчейна задать дополнительные файлы для цели clean.

посмотрел я тут на то, что у меня в PATH творится, и ужаснулся. Более того, ужаснулся тому, что средствами баша как-то неудобно этот бардак в порядок приводить. В итоге пришлось призвать питон для решения задачи добавления в и удаления из PATH, LD_LIBRARY_PATH и прочих похожих переменных всяких разных путей.

А как решают уважаемые спв эту проблему?