Сабж. Распространённая связка — это через сом-порт. Недавно появилась vmkd, обещающий ускорение коммуникации отлаживаемой системы с отладчиком, но только для vmware-сервера и пока бета.

Но ведь отлаживать можо и по usb, а это всяко быстрее СОМ. Можно ли как-то настроить? Или нужен драйвер, эмулирующий usb-шнурок с целевой системой?

Здравствуйте, IceStudent, Вы писали:

IS>Недавно появилась vmkd, обещающий ускорение коммуникации отлаживаемой системы с отладчиком, но только для vmware-сервера и пока бета.

Я тут между делом списался со Skywing'ом на предмет адаптации VMKD под Workstation, он мне пояснил, как vmxpatch.dll ищет нужные функции в vmware-vmx, и я подправил ее под Workstation 6.0.2. Вот исправленная DLL, положите ее вместо оригинальной.

У меня почему-то виртуальная машина после успешной активации VMKD начинает сильно тормозить (замедление в 3-4 раза), но загрузка процессора при этом не растет. Выяснилось, что kdvmware.sys почему-то слишком часто (десятки раз в секунду) дергает хост, отчего производительность сильно снижается. Причем у меня это не только на десктопе, где Workstation 6.0.2, но и на ноутбуке, где я ради эксперимента поставил Server 1.0.4 и оригинальный VMKD. Возможно, причина в том, что у меня на обоих компах процессоры AMD. Или в том, что в моих гостевых системах какие-то особенные настройки. Пока не можем выяснить, в чем проблема

IS>Но ведь отлаживать можо и по usb, а это всяко быстрее СОМ. Можно ли как-то настроить?

Нет, конечно. Отладка виртуальной машины через последовательный порт медленна не потому, что порт имеет фиксированную скорость, а потому, что данные через порт пересылаются побайтно, и на пересылку каждого байта уходит хренова гора операций по программной эмуляции поведения аппаратного порта. У VMX есть недокументированный параметр "serial<n>.pipe.charTimePercent = <n>", задающий уменьшение или увеличение времени на передачу байта через порт, но даже установка его в нуль почти ничего не меняет, ибо эмуляция, даже на двух гигагерцах, тормозит сильнее.

А отладка виртуальной машины по USB не имеет смысла потому, что пришлось бы на стороне гостевой системы городить интерфейс KDCOM к USB, который гораздо сложнее в программировании, нежели COM, а на стороне хоста — виртуальное USB-устройство для отладчика. Эмуляции было бы в несколько раз больше, а скорость — еще ниже.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А отладка виртуальной машины по USB не имеет смысла потому, что пришлось бы на стороне гостевой системы городить >интерфейс KDCOM к USB, который гораздо сложнее в программировании, нежели COM,

я думаю, в исходном сообщении имелась в виду, встроенная в ОС (начиная с Vista) поддержка отладки через usb — kdusb

>а на стороне хоста — виртуальное USB-устройство для отладчика. Эмуляции было бы в несколько раз больше, а скорость -> еще ниже.

у usb нет таких ограничений как у serial порта, со скоростью все должно быть в порядке.
вопрос только в том как перенаправить данные в отладчик без физического подключения по usb к vmware хосту.
перенаправлять usb через ethernet уже умеют — http://www.fabulatech.com/usb-over-network.html

Здравствуйте, Ivan, Вы писали:

I>у usb нет таких ограничений как у serial порта, со скоростью все должно быть в порядке.

Какие ограничения имеются в виду?

Здравствуйте, Евгений Музыченко, Вы писали:

I>>у usb нет таких ограничений как у serial порта, со скоростью все должно быть в порядке.
ЕМ>Какие ограничения имеются в виду?

здесь: http://www.intel.com/technology/magazine/computing/it09021.pdf

Debug port also has additional benefits not found in serial port solutions. Its transmission rate is roughly 512 KBaud. It also benefits from the flow control inherent in USB. This eliminates the transmission overruns and data resends that are so prevalent with serial port connections.

интересный вопрос — виртуализирует ли vmware usb debug port

Здравствуйте, Ivan, Вы писали:

I>>>у usb нет таких ограничений как у serial порта, со скоростью все должно быть в порядке.
ЕМ>>Какие ограничения имеются в виду?

I>

I>Debug port also has additional benefits not found in serial port solutions. Its transmission rate is roughly 512 KBaud. It also benefits from the flow control inherent in USB. This eliminates the transmission overruns and data resends that are so prevalent with serial port connections.

В случае виртуальной машины, паспортная скорость порта, как уже говорилось, не имеет никакого значения. Со flow control у последовательного порта тоже нет никаких проблем. Единственная выгода USB — возможность пакетной, а не побайтной, передачи данных. Именно за счет этого и выигрывает VMKD.

I>интересный вопрос — виртуализирует ли vmware usb debug port

Вряд ли — оно эмулирует чипсет 440BX, там этого порта быть не должно.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В случае виртуальной машины, паспортная скорость порта, как уже говорилось, не имеет никакого значения.
судя по посту Skywing имеет — http://www.nynaeve.net/?p=167

Because the virtual serial port has to act like a real serial port, it’s also slow, just like a real serial port (otherwise, timings get off and programs that talk to the serial port break all over the place). This means that although you might be debugging a completely local VM, you’re still throttled to serial port speeds (115200bps).

Здравствуйте, Евгений Музыченко, Вы писали:

I>>интересный вопрос — виртуализирует ли vmware usb debug port
ЕМ>Вряд ли — оно эмулирует чипсет 440BX, там этого порта быть не должно.

для отладки через usb нужна поддержка USB 2.0, vmware workstation поддерживает usb 2.0 (с версии 6.0Ю если не ошибаюсь) — для этого нужно что-то поновее, чем 440bx

Здравствуйте, Ivan, Вы писали:

I>

although you might be debugging a completely local VM, you’re still throttled to serial port speeds (115200bps).

На это ему уже ответили с указанием параметра serial<n>.pipe.charTimePercent. Только смысла в нем для высоких скоростей нет — все равно эмуляция тормозит сильнее. Нужен именно пакетный интерфейс.

I>для отладки через usb нужна поддержка USB 2.0, vmware workstation поддерживает usb 2.0 (с версии 6.0Ю если не ошибаюсь) — для этого нужно что-то поновее, чем 440bx

Для отладки через USB нужен прежде всего соответствующий порт USB

IS>Но ведь отлаживать можо и по usb, а это всяко быстрее СОМ. Можно ли как-то настроить? Или нужен драйвер, эмулирующий usb-шнурок с целевой системой?

У меня сейчас несколько вариантов отладки как виртуальных машин ( у меня их три: VMWare, VirtualPC, Parallels ), так и реальных через IEEE1394. Я не могу сказать, что отладка через быстрый интерфейс намного отличается по скорости от отладки виртуальной машины через медленный виртуальный порт. Есть некоторые операции, которые работают гораздо быстрее. В основном, это операции связанные с передачей большого объема информации, к примеру .kdfiles, !process. Но штука вся в том, что большая часть времени в отладчике тратиться на обычную трассировку, а вот она не слишком то зависит от скорости интерфейса и выигрыша практически не ощущается. У меня сложилось впечатление, что основной тормоз при трассировки — это наличие большого количества отладочной информации, которую windbg постоянно пытается применять . Я ради интереса отлаживал драйвер без символов ядра и пр — скорость явно выросла.

PS: естественно, хост система должна быть многопроцессорной, иначе отладчик начнет делить процессор с виртуальной машиной и наступит ппц .

Здравствуйте, TarasCo, Вы писали:

TC>У меня сейчас несколько вариантов отладки как виртуальных машин ( у меня их три: VMWare, VirtualPC, Parallels ), так и реальных через IEEE1394. Я не могу сказать, что отладка через быстрый интерфейс намного отличается по скорости от отладки виртуальной машины через медленный виртуальный порт. Есть некоторые операции, которые работают гораздо быстрее. В основном, это операции связанные с передачей большого объема информации, к примеру .kdfiles, !process.
quote from here:

Note that 1394 can still write physical memory dumps faster than VMKD, because 1394 KD can essentially DMA the target’s physical memory across the wire due to special support in the 1394 DbgEng KD protocol client.

TC>Но штука вся в том, что большая часть времени в отладчике тратиться на обычную трассировку, а вот она не слишком то зависит от скорости интерфейса и выигрыша практически не ощущается. У меня сложилось впечатление, что основной тормоз при трассировки — это наличие большого количества отладочной информации, которую windbg постоянно пытается применять . Я ради интереса отлаживал драйвер без символов ядра и пр — скорость явно выросла.
да, есть такое дело. причем это применение доп "умной" логики windbg естественно производит массу запросов не только к символьному серверу, но и к debuggee/target что под отладкой... а это все складывается в тормоза

ок, поделюсь своим опытом — еще иногда бывает полезным вот какой трюк: вместо того чтобы звать !process 0 <много всяких флагов> или !locks на живой машине с медленным соединением, большим ресурсов на ней использующихся (куча процессов болтается в памяти и т.п.) и затем ждать выхлопа, возможно, часами — можно сделать финт ушами: записать дамп памяти ядра через .dump и натравить все те же команды уже на него. Это в разы уменьшает время на получение интересующей информации и особенно при последующем статическом анализе дампа (при поиске дедлоков например часто не нужно живой отладки, достаточно дампа) — потому что содержимое памяти выкачивается раз, а в случае живой отладки траффик между debuggee и хостом во много раз может превышать траффик от получения дампа — и на медленных коннектах (отладка кастомеров в лесу с плохим сетевым соединением, например) иногда дает существенную экономию.

Если ситуация стабильно воспроизводимая и есть возможность — можно для уменьшения времени записи дампа также еще урезать кол-во используемой памяти в boot.ini через /MAXMEM — выставить в 192/256/384 метра и на машине с 4+ Гб вместо высасывания ерунды — записать только то, что реально нужно.

VAB>

Note that 1394 can still write physical memory dumps faster than VMKD, because 1394 KD can essentially DMA the target’s physical memory across the wire due to special support in the 1394 DbgEng KD protocol client.

Я сравнивал скорость с обычным виртуальным портом, не ускоренным.

Здравствуйте, TarasCo, Вы писали:

TC>Я не могу сказать, что отладка через быстрый интерфейс намного отличается по скорости от отладки виртуальной машины через медленный виртуальный порт.

Завидую Когда не работаешь с реальным временем — оно так и получается. А когда отлаживаешь тот же звуковой драйвер — вывод отладочных сообщений просто-таки катастрофически тормозит машину. Впрочем, сообщения с уровня DPC в любом случае лучше писать в память, ибо убогая реализация DbgPrint слишком затратна

TC>Но штука вся в том, что большая часть времени в отладчике тратиться на обычную трассировку, а вот она не слишком то зависит от скорости интерфейса и выигрыша практически не ощущается.

Не пробовал еще трассировку через VMKD, а через пайп трассировка в WinDbg ужасно медленна.

TC> У меня сложилось впечатление, что основной тормоз при трассировки — это наличие большого количества отладочной информации, которую windbg постоянно пытается применять

Похоже на то

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>

Note that 1394 can still write physical memory dumps faster than VMKD, because 1394 KD can essentially DMA the target’s physical memory across the wire due to special support in the 1394 DbgEng KD protocol client.

Что-то я не понял, какой смысл у этого сравнения, если 1394 работает с железной машиной, а VMKD — с виртуальной?

ЕМ>Завидую Когда не работаешь с реальным временем — оно так и получается. А когда отлаживаешь тот же звуковой драйвер — вывод отладочных сообщений просто-таки катастрофически тормозит машину.

У меня машина под отладчиком с выводом через 1394 также стоит минутами, мышью не двинуть. А всего то выводились адреса ip пакетов и еще кой чего. Мне так показалось, что тут основной тормоз опять же отладчик, по ощущениям он не отпускает таргет машину ( процессор ) пока не выведет свое отладочное сообщение, а это процесс как известно не очень быстрый . Так что опять тут IMHO не велик прок от быстрого интерфейса.

Кстати, попробуйте выводить отладочные сообщения через WMI, скорость вывода в лог файл будет на порядки выше.

Здравствуйте, TarasCo, Вы писали:

TC>Кстати, попробуйте выводить отладочные сообщения через WMI, скорость вывода в лог файл будет на порядки выше.

У меня уже есть встроенная возможность писать в память (кольцевой буфер). Я туда пишу все сообщения, а через DbgPrint вывожу только с важностью не менее заданной. Когда надо разбираться — просто сливаю весь буфер через WinDbg в файл на хосте, и смотрю. Разбираться-то надо в то время, пока таргет стоит на стопе — локальное WMI тут не годится.

ЕМ> Разбираться-то надо в то время, пока таргет стоит на стопе — локальное WMI тут не годится.

windbg кстати можно настроить на чтение WPP сообщений. Работать должно быстрее — поскольку передаваться то будет не сообщение, а его грубо говоря номер и параметры. А расшифровываться оно будет уже на хосте. Т.е по сути, все уже украдено до нас — циклобуфер то есть . Ну и гибкость определенная будет — хошь в отладчик пиши, хошь в лог файл. Единственно, я не знаю можно ли сделать так, чтобы сообщения выводились и в отладчик и обрабатывались еще и на хосте ( допустим, складывались в файл ). И если бы еще кто-нибудь сделал нормальную утилиту для просмотра WPP логов — цены не было б такому человеку , а то, что в WDK есть — больно уж неудобная, а главное глюченная поделка .

IS>Но ведь отлаживать можо и по usb

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

Эта железка не эмулируется в VMWare в госте, следовательно, забыли такую идею. Впрочем, возможно, заработает так — иметь эту железку физически, и воткнуть ее обеими концами в 2 USB разъема, при этом второй отдать полностью гостю VMWare.

Через 1394 можно отлаживаться, начиная с XP (нужна XP и на хосте, и на таржете), но опять же — если и есть поддержка 1394 в гостях VMWare, то она не поддерживает общий 1394 кабель с реальной железкой на хосте. Такое поддерживается только для эзернетов.

Так что — или сериальный порт, выведенный в пайп, или нативные средства отладки от новой VMWare.

Здравствуйте, Ivan, Вы писали:

I>я думаю, в исходном сообщении имелась в виду, встроенная в ОС (начиная с Vista) поддержка отладки через usb — kdusb
И да, и нет. В первую очередь интересовала поддержка отладки через usb в младших системах.