Можно ли (теоретически) создать тулзу для записи полного лога (небольшой части) работы ВМ - все выполненные инструкции+I/O+memory R/W, с возможностью "воспроизведения" работы ВМ из этого лога?

| Сообщение посчитали полезным:

spinz

Какой именно вм, это понятие слишком растяжимое. В любом случае придётся сворачивать выполняемый код, выделяя повторные проходы, таким образов обьединять инструкции в блоки/циклы/функции. А это не простая задача. Иначе лог получится бесконечно большим и бесполезным.

-----
vx

| Сообщение посчитали полезным:

difexacaw

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

| Сообщение посчитали полезным:

spinz

ОС выполняет огромное количество инструкций, причём параллельно и на железе. На секундный лог не хватит никакой дисковой памяти, это безумная, невозможная и глупая задача.
Дамп какой то локальной вм возможен и думаю актуален. Даже гпв нт работает на конкретных событиях, а не на трассировке инструкций. Так что для начала вам нужно как всегда сформулировать задачу/цель. Так как это далее определит решение. Такое пилится всегда исходя из главного - эффективности работы(минимальный тайминг). Именно это значительно усложняет задачу, так как придётся выбирать самый эффективный алгоритм в каждой части задачи и как то их совместить. Это всегда так сложно ддя реалтайм вм

-----
vx

| Сообщение посчитали полезным:

difexacaw
Если взять одноядерную гостевую ВМ, то параллельности не будет. И инструкций за одну секунду не так уж и много, если конечно проц не нагружен на 100%, что бывает редко. Ну пусть даже по максимуму будет 3-4млрд инструкций в секунду (что крайне завышенная цифра), по 4 байта на инструкцию (что тоже завышено) - даже без свертки кода на терабайтный диск уже влезет минута работы ВМ.

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

P.S. Что такое гпв нт?

P.P.S. Думаю, подобная тулза была бы в отдельных случаях востребована.

| Сообщение посчитали полезным:

spinz

Понятие загрузки проца лишь условно, то что вы видите в диспетчере задач статистику - оно не отображает реальную работу проца. Он никогда не останавливается. На младших версиях процов был реализован холодильник" - остановка выполнения через halt. Это уже давно не актуально, учитывая загрузку системы.

> по 4 байта на инструкцию (что тоже завышено) - даже без свертки кода на терабайтный диск уже влезет минута работы ВМ.

Чего 4 байта ?

А как же механизм трансляции, это намного больше займёт памяти. Есчо n*4 на трансляцию. И только для линейного сохранения адресов каждой инструкции. Без выборок данных. На запуск блокнота не хватит никакого диска. Впрочем не важно.

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

P.S. Что такое гпв нт?

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

Задача как алгоритмическая весьма интересна, но это уже не конкретно тз, а чисто алгоритмическая и абстрактая задача по свёртке кода. Именно к этому сводится исходная задача и так она должна быть сформулирована.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Чего 4 байта ?
А как же механизм трансляции, это намного больше займёт памяти. Есчо n*4 на трансляцию. И только для линейного сохранения адресов каждой инструкции. Без выборок данных. На запуск блокнота не хватит никакого диска. Впрочем не важно.

Ну я для простоты предположил, что каждая инструкция занимает в среднем 4 байта (конечно меньше). Адреса инструкций в общем случае хранить не нужно, т.к. стартуя с определенной точки (снапшота ВМ) и "выполняя" последовательно инструкции из лога, ВМ естественным образом повторит всю работу проца, в т.ч. и вычисление текущего IP. По аналогии с восстановлением из бэкапа базы SQL-сервера - имея исходный бэкап (снапшот) и зная все последующие тразакции, сервер может восстановить конечное состояние БД на момент последней записанной в журнал транзакции. Нужно только отслеживать смену IP из-за интерраптов, которые конечно тоже придется сохранять в лог.

difexacaw пишет:
Он никогда не останавливается.
Ну выборка и выполнение инструкций останавливается же после hlt и mwait, хотя tsc, конечно, продолжает увеличиваться. Впрочем, можно проц и в S1 отправить, тогда и tsc будет стоять

| Сообщение посчитали полезным:

Забавно когда человек не зная принципов работы железа и архитектуру видит аналогию с пхп скриптами

-----
vx

| Сообщение посчитали полезным:

Да ладно тебе, индий, и работу железа, и архитектуру я знаю гораздо лучше тебя.

| Сообщение посчитали полезным:

spinz пишет:

Да ладно тебе, индий, и работу железа, и архитектуру я знаю гораздо лучше тебя.

Не знаешь.
А если бы знал, то не городил бы тут чушь про базы SQL сервера.

-----
http://ntinfo.biz

| Сообщение посчитали полезным: difexacaw

Вот еще один не умеет в аналогии

| Сообщение посчитали полезным:

spinz пишет: даже без свертки кода на терабайтный диск уже влезет минута работы ВМ

Хорошая шутка. В реальной жизни хорошо если минута работы блокнота со связанными данными влезет в терабайт

spinz пишет: Вот еще один не умеет в аналогии

Аналогия звучит примерно так: "Земля она круглая, начертим круг и как видим он очень простой, можно всю землю перенести на лист бумаги, главное больше слонов с китами добавить"..

| Сообщение посчитали полезным:

hors

Согласен, после #7 понял что это за тема и что за человек, какой у него масштаб знаний. А изначально вопрос довольно интересный. Это чисто алгоритмическая задача по выделению кода и подобному. Я тут поднимал частную задачу по выделению циклов --> Link <--

Задача тс куда сложнее, это полноценное выделение повторно исполняемых блоков. Это просто решается без использования бд и какого либо связывания, те как алгоритм. Но реально нужны довольно гибкие связанные структуры, со сложной организацией, которую нужно продумать. Думаю именно в этом проблема.

-----
vx

| Сообщение посчитали полезным:

> Но реально нужны довольно гибкие связанные структуры, со сложной организацией, которую нужно продумать.

Смысл хранить пустую трассу без данных и ко всему прочему без свертки циклов?
С таким же успехом можно запустить софт заново, эффект будет такой же.
Для реализации time travel необходимо сохранять внушительные куски памяти, а в случае с операционной системой, это придется делать часто и сохранять много. Иначе эта трасса будет просто мусором, такую самому можно генерировать рандомом, используя таблицу частот инструкций, пользы от нее будет столько же.
Сохранение трассы состояний операционной системы это конечно же шиза, а для софта вполне практичная задача, можно делать снапы на входе в функцию и откатываться назад во время отладки, только всё украдено задолго до нас. Этой идеи лет больше чем мне и были реализации, windbg частично умеет.

| Сообщение посчитали полезным: difexacaw

shellstorm пишет:
Смысл хранить пустую трассу без данных и ко всему прочему без свертки циклов?
С таким же успехом можно запустить софт заново, эффект будет такой же.

Не шаришь. Имея исходное состояние(снапшот) + лог инструкций + I/O и интерраптов, можно в точности восстановить на любой момент времени весь контекст работы ВМ (регистры/память/диск)

| Сообщение посчитали полезным:

spinz

Да по вашему все не шарят, он всё верно выше сказал, вы просто не поняли.

Смотрите, к примеру некий системный код в области быстрой и не прерывной обработки(шедулер) сохраняется в лог. В памяти одна и та же инструкция за секунду выполняется миллионы раз. Если отсутствует структурное связывание(не известна предыдущая инструкция или в общем caller"), то инфа про инструкцию есть просто статистическая(таймер-счётчик). Эта инфа соотвественно бесполезна. Утеря хоть одной инструкции из их огромного потока приведёт к отсутствию связывания и бессмысленности всей затеи.

Думаю следует исключить из данной задачи ос-вм, задача не имеет смысла.

В случае софт вм пример свёртки вы можите глянуть, тут где то был мой пример. Код выделялся из исполнения и d-fetch овер гб-цикла итераций(vmp). Без такой свёртки лог будет расти бесконечно и крайне быстро.

Думаю вы это поняли, задача сформулирована. Вам нужно теперь подумать над реализацией свёртки кода - как выделить повторно используемые блоки, причём с учётом вложенности/рекурсивно и с предельно эффективным по размеру использованием памяти на хранение структур, связующих блоки.

-----
vx

| Сообщение посчитали полезным:

Внезапно подумалось, что для точного воспроизведения работы ВМ лог инструкций не нужен вообще. Достаточно снапшота и лога интерраптов+I/O. Инструкции проц автоматом возьмет из памяти, сохраненной в снапшоте.

| Сообщение посчитали полезным:

Вот и поговорили

Отличная мотивация на задачу у тс.. тут особо и сказать нечего. У меня детектор реагирует на тролей или пустых" людей, он сработал и редко ошибается.)

-----
vx

| Сообщение посчитали полезным:

spinz пишет:
Можно ли (теоретически) создать тулзу для записи полного лога (небольшой части) работы ВМ - все выполненные инструкции+I/O+memory R/W, с возможностью "воспроизведения" работы ВМ из этого лога?
Всё давно изобретено виртуальная машина с snapshots

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

ClockMan

Одного снапшота недостататочно для точного воспроизведения работы ВМ. Тот же сетевой трафик в разные моменты времени будет разным, значит и работа ВМ будет отличаться.

| Сообщение посчитали полезным:

> Всё давно изобретено виртуальная машина с snapshots

Снап vm сохраняет одно состояние операционной системы, а ТС хочет из одного состояния сделать back\up trace, то есть по сути из одного сохраненного состояния воспроизвести множественные снапы vm.)

| Сообщение посчитали полезным:

Чисто гипотетически (c) - сервер падает раз в сутки раз в неделю. Как отлаживать?
Воспроизведение лога ВМ с учетом записанного трафика могло бы сильно помочь

| Сообщение посчитали полезным:

spinz пишет:
Чисто гипотетически (c) - сервер падает раз в сутки раз в неделю. Как отлаживать?
Добавить эксепшен-хэндлер с сохранением на диск ошибки перед вылетом?

Добавлено спустя 1 минуту
Ну а лучше по эксепшен гоу ту дебаггер

-----
IZ.RU

| Сообщение посчитали полезным:

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

А эта ситуация повторится в следующий раз через три недели.

Как будешь ловить ошибку?


А есл записать лог ВМ i/o от снапшота до ошибки, то ошибку всегда можно будет воспроизвести

| Сообщение посчитали полезным:

Похоже это то что тебе нужно:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg529435.html

| Сообщение посчитали полезным: