From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Virus-Scanned: amavisd-new at elserv.ru To: ALT Linux Sisyphus discussions References: <841FF6BE-7C06-4994-B8E9-008F95CB3068@ntechs.ru> From: Alex Moskalenko Message-ID: Date: Fri, 14 Oct 2016 10:19:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <841FF6BE-7C06-4994-B8E9-008F95CB3068@ntechs.ru> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sisyphus] Xen-4.7.0 X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 07:19:58 -0000 Archived-At: List-Archive: List-Post: 27.09.2016 09:04, Dmitriy D. Shadrinov пишет: > Здравствуйте, > хочу предложить сборку Xen-4.7.0: http://git.altlinux.org/tasks/169981/ > Здравствуйте! А есть ли что-нибудь, мешающее скопировать эту сборку в P8? Хотелось бы тестировать/использовать ее в более стабильном окружении. По результатам тестирования получилось следующее. Система - обновленный P8, ядра - 4.4.23-std-def и 4.7.7-un-def. 1. Насколько оправдана зависимость xen-runtime на xen-hypervisor-abi? xen-runtime требуется для функционирования "driver domain"'ов, а вот самому гипервизору там делать нечего; 2. На ядрах 4.4.23-std-def не запускается xl devd (вылетает на -ENOPERM при доступе к /dev/xen/privcmd), что не позволяет использовать Driver Domains (для сети например). На 4.7.7-un-def - ве отлично; 3. Не удалось запустить HVM-домены с Device Model Stub Domains - домен с device model падает, соответственно без него основной домен не запускается. Поведение (и логи) одинаковые как при Linux, так и при Windows. Лог падения следующий: evtchn_open() -> 6 xenevtchn_bind_interdomain(28, 3) = 0 GPF rip: 96a4f, error_code=0 Thread: main RIP: e030:[<0000000000096a4f>] RSP: e02b:00000000005cf860 EFLAGS: 00010006 RAX: 0000200000006840 RBX: 0000000000000006 RCX: 0000000000000012 RDX: 0000000000000006 RSI: 0000000000000000 RDI: 0000000000000006 RBP: 00000000005cf880 R08: 000000000000000a R09: 0000000000000001 R10: 000000000014268b R11: 0000000000000000 R12: 0000000000000200 R13: 0000000000000006 R14: 000000000015daa0 R15: 0000000000001000 base is 0x5cf880 caller is 0xd342f base is 0x5cf8a0 caller is 0xd59ca base is 0x5cf8e0 caller is 0xd5a21 base is 0x5cf900 caller is 0xd5a80 base is 0x5cf910 caller is 0x96d62 base is 0x5cf960 caller is 0x218e7 base is 0x5cf990 caller is 0x2928e base is 0x5cfa40 caller is 0x29fd9 base is 0x5cfa60 caller is 0x1d0e3 base is 0x5cfad0 caller is 0x901e base is 0x5cfe10 caller is 0xd6772 base is 0x5cffe0 caller is 0x3423 5cf850: 60 f8 5c 00 00 00 00 00 2b e0 00 00 00 00 00 00 5cf860: 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5cf870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5cf880: a0 f8 5c 00 00 00 00 00 2f 34 0d 00 00 00 00 00 5cf870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5cf880: a0 f8 5c 00 00 00 00 00 2f 34 0d 00 00 00 00 00 5cf890: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5cf8a0: e0 f8 5c 00 00 00 00 00 ca 59 0d 00 00 00 00 00 96a30: 05 48 c7 40 18 01 00 00 00 41 c7 84 24 f8 d9 15 96a40: 00 01 00 00 00 9c 41 5c 41 81 e4 00 02 00 00 fa 96a50: 48 8b 05 69 6f 0c 00 48 85 c0 74 19 0f 1f 40 00 96a60: 48 8b 58 10 48 8b 78 08 e8 cd 3a 04 00 48 85 db 4. На 4.4.23-std-def поймал сообщения от mptsas при активной работе с дисками: Oct 13 23:26:52 testxen47 kernel: [129482.991324] mptsas 0000:10:00.0: swiotlb buffer is full (sz: 65536 bytes) Oct 13 23:26:52 testxen47 kernel: [129482.991338] mptsas 0000:10:00.0: swiotlb buffer is full Oct 13 23:26:52 testxen47 kernel: [129482.991437] mptsas 0000:10:00.0: swiotlb buffer is full (sz: 65536 bytes) Oct 13 23:26:52 testxen47 kernel: [129482.991446] mptsas 0000:10:00.0: swiotlb buffer is full Oct 13 23:26:52 testxen47 kernel: [129482.999807] mptsas 0000:10:00.0: swiotlb buffer is full (sz: 65536 bytes) Oct 13 23:26:52 testxen47 kernel: [129482.999807] mptsas 0000:10:00.0: swiotlb buffer is full Oct 13 23:26:52 testxen47 kernel: [129483.003336] mptsas 0000:10:00.0: swiotlb buffer is full (sz: 65536 bytes) Oct 13 23:26:52 testxen47 kernel: [129483.003336] mptsas 0000:10:00.0: swiotlb buffer is full В рассылках об этом пишут, вроде как не страшно, но работу замедляет. К тому же, через 3 дня нагрузочного тестирования (HVM Linux+HVM Windows+PV Linux+network driver domain) с помощью iometer и iperf получил полный фриз Domain0 (и всего остального соответственно) на попытках доступа к дискам; 5. на 4.4.23-std-def несколько раз поймал "skb rides the rocket" в xen-netfront. Сеть при этом правда не отвалилась, как часто происходило раньше на ядрах 3.х. На данный момент тестирую все Linux-домены c 4.7.7-un-def и Windows 2012 с последними PV-драйверами. Продвинутые методы работы с сетью (типа checksumming и scatter-gather) не отключал. Будет еще что-то интересное - отпишусь. PS Хотелось бы оторвать зависимость xen-runtime на xen-hypervisor-abi и починить Device Model Stubdomains.